Параллельное и распределенное программирование на С++ - Хьюз Камерон

• Количество вызовов, требуемых для запуска потока, в этом случае возросло бы от одного до двух, что, таким образом, возложило бы излишние расходы на приложения, которым не нужна дополнительная синхронизация. Однако второго вызова можно было бы избежать за счет усложнения атрибута состояния запуска.

• Для потока пришлось бы вводить дополнительное состояние, которое можно определить как «созданный, но не активизированный». Это потребовало бы введения стандарта для определения поведения операций потока в случае, когда поток еще не начал выполняться.

• Для приложений, которым подходит именно такое поведение, можно сымитировать два отдельных действия с использованием существующих средств. Функцию start_routine () можно синхронизировать путем организации ожидания по условной переменной, сигнализируемой операцией активизации потока.

При реализации Ada-приложений можно создавать потоки в любой из двух точек Ada-программы: при создании объекта задачи или при ее активизации. В случае принятия первого варианта функции start_routine () пришлось бы ожидать по условной переменной получения «приказа» начать активизацию. Второй вариант не требует использования условной переменной или дополнительной синхронизации. В любом случае при создании объекта задачи потребовалось бы создание отдельного блока управления Ada-задачей, чтобы поддерживать рандеву-очереди.

Расширение упомянутой модели позволило бы модифицировать состояние потока между созданием и активизацией, и, следовательно, удалить объект атрибутов потока. Это предложение было отвергнуто по таким причинам.

• Должна существовать возможность установки любого состояния в объекте атрибутов потока. Это потребовало бы определения функций для модификации атрибутов потока, что не уменьшило бы количество вызовов, необходимых для установки потока. На самом деле для приложения, которое создает все потоки с использованием идентичных атрибутов, количество вызовов функций, необходимых для установки потоков, резко бы возросло. Использование объектов атрибутов потока позволяет приложению создать один набор вызовов функций установки атрибутов. В противном случае набор вызовов функций установки атрибутов пришлось бы делать для создания каждого потока.

• В зависимости от архитектурного решения функции установки состояния потока потребовали бы вызовов функций ядра системы или (по каким-то иным причинам) не могли быть реализованы как макросы, что увеличило бы расходы ресурсов на создание потока.

• Была бы утеряна возможность «классовой» организации потоков для приложений.

Предлагалась еще одна альтернатива, в которой рассматривалось использование модели, аналогичной созданию процессов, — «разветвление потока». Семантика разветвления обеспечивала бы большую гибкость, и функцию создания можно было реализовать в виде простого разветвления потока, за которым немедленно следовал вызов требуемой «запускающей» функции. Этот вариант имел такие недостатки.

• Для многих реализаций внутренний стек вызывающего потока пришлось бы дублировать, поскольку во многих архитектурах нет возможности определить размер вызывающего фрейма.

• Эффективность снизилась бы, поскольку пришлось бы копировать по крайней мере некоторую часть стека, несмотря на то, что в большинстве случаев после вызова нужной «запускающей» функции потоку уже не требуется скопированный контекст.

Будущие направления

Отсутствуют.

Смотри также

fork (), pthread_exit () , pthread_join (), то м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функция впервые реализована в выпуске Issue 5. Включена для согласования с расширением POSIX Threads Extension.

Issue 6

Функция pthread_create () от м ечена как часть опции Threads.

В результате согласования со спецификацией Single UNIX Specification был добавлен обязательный код ошибки [EPERM].

С целью согласования со ста н дарто м IEEE Std 1003.1d-1999 для потока была добавлена се м антика тай м ера центрального процессора.

Для согласования со стандарто м ISO/IEC 9899: 1999 в прототип функции pthread_create () было добавлено ключевое слово restrict.

В раздел «Описание» внесено явное утверждение о то м, что среда обработки данных с плаваю щ ей точкой наслелуется от создаю щ его потока.

pthread_detach

Имя

pthread_detach — функция отсоединения потока.

Синопсис

THR

#include <pthread.h>

int pthread_detach (pthread_t thread);

Описание

Функция pthread_detach () уведомляет реализацию о том, что область памяти для потока thread может быть восстановлена, когда он завершит выполнение. Если поток не завершается, функция pthread_detach () не служит причиной для его завершения. Результат нескольких вызовов функции pthread_detach () для одного и того же потока не определен.

Возвращаемое значение

При успешном завершении функция pthread_detach () возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_detach () завершится неудачно, если:

[EINVAL] реализация обнаружила, что значение, заданное параметром thread, не относится к присоединенному потоку;

[ESRCH] не был найден ни один поток, соответствующий заданному идентификационному номеру потока ID.

Эта функция не возвращает код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Функции pthread_join() или pthread_detach() должны вызываться для каждого потока, который создается, чтобы можно было снова использовать область памяти, связанную с потоком.

Высказывалось мнение о необязательности использования функции pthread_detach (): поскольку поток никогда динамически не отсоединяется, то достаточно использовать атрибут создания потока detachstate. Однако необходимость в этой функции возникает по крайней мере в двух случалх.

1. В обработчике запроса на отмену для функции присоединения потока (pthread__join()) важно иметь функцию pthread_detach(), чтобы отсоединить поток. Без нее обработчик вынужден был бы выполнить еще раз функцию pthread_j oin (), чтобы попытаться отсоединить поток, который не только задерживает процедуру отмены в течение неограниченного времени, но и вносит новый вызов функции pthread_join(). В этом случае есть смысл говорить о динамическом отсоединении.

2. Чтобы отсоединить «исходный поток» (это может понадобиться в процессах, которые создают потоки сервера).

Будущие направления

Отсутствуют.

Смотри также

pthread_join (), том Base Definitions стандарта IEEE Std 1003.1-2001, <pthread. h>.

Последовательность внесения изменений

Функция впервые реализована в выпуске Issue 5. Включена д ля согласования с расширение м POSIX Threads Extension.

Issue 6

Функция pthread_detach () отмечена как часть опции Threads.

pthread_exit

Имя

pthread_exit — функция завершения потока.

Синопсис

THR #include <pthread.h>

void pthread_exit (void *va2ue_ptr);

Описание

Функция pthread_exit() завершает вызывающий поток и делает значение value _ptr доступны м для успешного присоединения к завершающе м у потоку Любые обработчики отмены, которые были помещены в стек, но еще не извлечены из него, будут извлечены в порядке, обратном тому, в котором они помещались туда, а затем выполнены. Если потоку принадлежат данные, то после выполнения всех обработчиков отмены булут вызваны соответствующие функции деструкторов (в неопределенном порядке). При завершении потока ресурсы процесса, включая мьютексы и дескрипторы файлов, не освобождаются, и не выполняются какие бы то ни было «восстановительные» действия уровня процесса, включал вызовы любых функций atexit(), какие только могут существовать.