MyWackoSite: КурсОперационныеСистемы/ПрактикумPosixThreads/PthreadLectures/CreateExit ...

В ходе этого раздела вы изучите

• Создание нитей с атрибутами по умолчанию
• Передачу параметров нити
• Завершение нити
• Ожидание завершения другой нити
• Принудительное завершение нити
• Обработку принудительного завершения нити

Создание нитей с атрибутами по умолчанию

В POSIX Thread API нить создается библиотечной функцией pthread_create(3C).

Параметры этой функции:


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

Коды ошибок

Пример 1
#include <stdio.h> #include <stdlib.h> #include <pthread.h> #include <string.h> void * thread_body(void * param) { sleep(1); printf("Child\n"); } /* * creates thread with default attributes and no parameters * sleeps enough time to ensure that thread will print his message * (under reasonable conditions) */ int main(int argc, char *argv[]) { pthread_t thread; int code; int i; code=pthread_create(&thread, NULL, thread_body, NULL); if (code!=0) { char buf[256]; strerror_r(code, buf, sizeof buf); fprintf(stderr, "%s: creating thread: %s\n", argv[0], buf); exit(1); } sleep(5); return (EXIT_SUCCESS); }

Завершение нити

Для завершения нити используется функция pthread_exit(3C). Эта функция всегда завершается успешно и принимает единственный параметр, указатель на код возврата типа void *. Как и в случае с pthread_create(3C), библиотека никогда не пытается обращаться к значению этого параметра как к указателю, поэтому его можно использовать для передачи скалярных значений.

Другой способ завершения нити – это возврат управления из функции start_routine при помощи оператора return. Поскольку функция start_routine должна возвращать тип void *, все ее операторы return должны возвращать значение. Этот способ практически полностью эквивалентен вызову pthread_exit(3C) с тем же самым значением.


Пример 2
#include <pthread.h> #include <unistd.h> #include <iostream> class TestClass { public: int value; TestClass(int parameter) { std::cout << "Constructed " << parameter << "\n"; value=parameter; } ~TestClass() { std::cout << "destructed " << value << "\n"; } }; extern "C" { void *body_forexit(void * param) { TestClass a(1); sleep(1); pthread_exit((void *)a.value); return (void *)a.value; } void *body_forreturn(void * param) { TestClass b(2); sleep(2); return (void *)b.value; } } // extern "C" int main() { pthread_t thread1, thread2; pthread_create(&thread1, NULL, body_forexit, NULL); pthread_detach(thread1); pthread_create(&thread2, NULL, body_forreturn, NULL); pthread_detach(thread2); pthread_exit(NULL); return 0; }






При использовании для размещения возвращаемого значения malloc(3C) возникает опасность утечки памяти. Действительно, если для размещения значения использовать malloc(3C), то нить, получающая наше значение, должна его освободить. Но если эта нить получит сигнал принудительного завершения (pthread_cancel(3C)), то она не дождется нашего завершения и не освободит наше значение.

Ожидание завершения нити

Для ожидания завершения нити и получения ее кода возврата используется библиотечная функция pthread_join(3C). Эта функция имеет два параметра, идентификатор нити типа pthread_t, и указатель на переменную типа void *, в которой размещается значение кода возврата. Если в качестве второго параметра передать нулевой указатель, код возврата игнорируется.

Если требуемая нить еще не завершилась, то нить, сделавшая вызов pthread_join(3С), блокируется. Если такой нити (уже) не существует, pthread_join(3C) возвращает ошибку ESRCH.

Когда нить завершается, то связанные с ней ресурсы существуют до того момента, пока какая-то другая нить не вызовет pthread_join(3C). Однако к тому моменту, кода pthread_join завершается, все ресурсы, занятые нитью (стек, thread local data, дескриптор нити) уничтожаются.

В отличие от процессов Unix, где системный вызов wait(2) может использовать только родитель по отношению к потомкам, любая нить может ждать завершения любой другой нити того же процесса. Если несколько нитей ждут завершения одной и той же нити, которая еще не завершилась, все эти нити блокируются. Однако при завершении нити одна из ожидавших нитей получает код возврата, а остальные ошибку ESRCH.

Если нить пытается ожидать сама себя, она получает ошибку EDEADLK.

Еще одна важная функция, связанная с ожиданием завершения нити – это функция pthread_detach(3C). Эта функция указывает, что все ресурсы, связанные с нитью, необходимо уничтожать сразу после завершения этой нити. При этом уничтожается и код возврата такой нити – при попытке сделать pthread_join(3C) на нить, над которой перед этим сделали pthread_detach(3C), возвращается код ошибки EINVAL.

В руководстве по pthread_detach(3C) в системе Solaris 10 сказано, что главное применение pthread_detach(3C) – это ситуация, когда родитель, ожидавший завершения дочерней нити, получает pthread_cancel(3C). В действительности, существуют и другие применения «отсоединенных» нитей.

Не обязательно делать pthread_detach(3C) на уже запущенную нить; в атрибутах нити (pthread_attr_t) можно указать, что нить следует запускать в уже «отсоединенном» состоянии. Это рассматривается в следующей лекции.

Разумеется, нить, над которой сделали pthread_detach(3C), не должна выделять память под возвращаемое значение при помощи malloc(3C) – ведь никто не сможет освободить эту память и это приведет к утечке памяти.

Рекомендованного стандартом способа проверить собственную «отсоединенность» нет. Из предыдущего описания можно предположить, что для проверки «отсоединенности» можно было бы использовать код возврата pthread_join(3C) для собственного идентификатора нитей – для «отсоединенных» нитей это должен быть EINVAL, а для «неотсоединенных» – EDEADLK. Для Solaris 10 и Linux 2.6 это действительно так (во всяком случае для Debian Sarge), однако в Linux 2.4 ptread_join(pthread_self(), NULL) всегда возвращает EDEADLK. Как ведет себя pthread_join на вашей системе, можно проверить при помощи программы примера 3.


Пример 3
#include <pthread.h> #include <errno.h> #include <unistd.h> #include <stdio.h> #include <string.h> /* !!! NEVER USE THIS IN PRODUCTION ENVIRONMENT!!!! */ /* Behavior of this code implementation-dependent * using this code "as is" will result in race condition */ void * thread_body(void *unused) { pthread_t self; int code; self=pthread_self(); code=pthread_join(self, NULL); printf("Joining self before detach, error code=%d, message %s\n", code, strerror(code)); /* NEVER USE THIS CODE IN PRODUCTION ENVIRONMENT */ pthread_detach(self); code=pthread_join(self, NULL); printf("Joining self after detach, error code=%d, message %s\n", code, strerror(code)); return NULL; } int main() { pthread_t thread; pthread_create(&thread, NULL, &thread_body, NULL); pthread_exit(NULL); return 0; }

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

Принудительное завершение нити

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

Нить может установить одну или несколько функций-обработчиков, которые будут вызваны при попытке прервать исполнение этой нити. Такие обработчики могли бы освободить дополнительные ресурсы, занятые нитью, например блоки динамической памяти или мутексы, или привести в согласованное состояние разделяемые структуры данных.

Момент, в который нить получает сообщение о попытке прервать ее исполнение функцией pthread_cancel(3C) контролируется атрибутами нити, известными как cancel state и cancel type.

Cancel state (состояние прерывания) определяет, разрешено ли прерывание нити как таковое. Т.е. этот атрибут может иметь два значения – разрешено или запрещено. Если прерывание разрешено, нить немедленно получает сообщение о попытке ее прервать (хотя, в зависимости от cancel type, может отреагировать на это сообщение лишь через некоторое время). Если прерывание запрещено, попытки прерывания нити накапливаются. После того, как прерывания все-таки разрешат, нить получит сигналы о накопившихся попытках.

Переключение состояния прерывания осуществляется функцией pthread_setcancelstate(3C). Первый параметр этой функции входной и может принимать значения PTHREAD_CANCEL_ENABLE (прерывание разрешено) и PTHREAD_CANCEL_DISABLE (прерывание запрещено). Эти значения – препроцессорные макроопределения, содержащиеся в файле pthread.h. Вызов функции с другими значениями первого параметра приведет к ошибке EINVAL. Второй параметр функции – выходной, содержит указатель на переменную, в которой будет размещено старое значение типа прерывания. В качестве этого указателя можно передать NULL, в этом случае старое значение состояния будет потеряно. По умолчанию, нить создается с разрешенными прерываниями.

Cancel type (тип прерывания) определяет, в какие моменты нить проверяет сообщения о прерываниях. Этот атрибут может принимать два значения – PTHREAD_CANCEL_DEFERRED (отложенное прерывание) и PTHREAD_CANCEL_ASYNCHRONOUS (асинхронное прерывание). По умолчанию, нить создается с отложенным типом прерываний.

Асинхронное прерывание означает, что библиотека прерывает нить как можно скорее (хотя во многих ситуациях не удается гарантировать, чтобы это происходило точно в тот момент, когда другая нить вызвала pthread_cancel(3С)). Асинхронное прерывание требует тщательного анализа всех возможных моментов, когда оно может произойти, и обработки всех ситуаций, связанных с прерываниями в неудачные моменты. Так, если прерывание произойдет во время работы с библиотекой, которая не считается thread-safe, внутренние данные этой библиотеки могут остаться в несогласованном состоянии. Кроме того, частый просмотр флага прерывания планировщиком нитей может приводить к потерям производительности.

Отложенное прерывание означает, что нить получает сообщение о прерывании лишь в определенные моменты, известные как точки прерывания (cancellation point). Эти точки, в свою очередь, делятся на две категории – явные и неявные. Явные точки прерывания – это вызовы функции pthread_testcancel(3C). Неявные точки прерывания – это вызовы следующих функций и системных вызовов:

aio_suspend(3RT), close(2), creat(2), getmsg(2), getpmsg(2), lockf(3C), mq_receive(3RT), mq_send(3RT), msgrcv(2), msgsnd(2), msync(3C), nanosleep(3RT), open(2), pause(2), poll(2), pread(2), pthread_cond_timedwait(3C), pthread_cond_wait(3C), pthread_join(3C), pthread_testcancel(3C), putmsg(2), putpmsg(2), pwrite(2), read(2), readv(2), select(3C), sem_wait(3RT), sigpause(3C), sigwaitinfo(3RT), sigsuspend(2), sigtimedwait(3RT), sigwait(2), sleep(3C), sync(2), system(3C), tcdrain(3C), usleep(3C), wait(3C), waitid(2), wait3(3C), waitpid(3C), write(2), writev(2), fcntl(2) (с командой F_SETLKW).

Список приведен для Solaris 10. Получить полный список неявных точек прерывания для вашей версии ОС можно получить на странице руководства cancellation(5).

Стандарт POSIX допускает наличие неявных точек прерывания в некоторых других системных вызовах и библиотечных функциях, которые перечислены на странице http://www.opengroup.org/onlinepubs/007908799/xsh/threads.html. Слушатели, знакомые с реализацией стандартных библиотек языка C должны заметить, что это преимущественно функции, которые содержат или могут содержать вызовы неявных точек прерывания, перечисленных выше. В частности, это большинство функций буферизованного ввода-вывода (printf(3C), fread(3C), fwrite(3C)).

Однако реализации POSIX Thread Library в Solaris 10 и Linux 2.6 не содержат неявных точек прерывания ни в одной из этих функций. Во всяком случае, в Solaris 10 список функций, содержащих неявные точки прерывания, приведенный на странице руководства cancellation(5), является исчерпывающим.

Слушателям, интересующимся вопросом, как удалось реализовать printf(3C) или fwrite(3C) без обращения к точке прерывания в теле write(2), я рекомендую обратиться к исходным текстам библиотеки языка C, размещенным на сайте http://www.opensolaris.org, или просто пройти в пошаговом отладчике код библиотечной функции fwrite(3C). Для этого предварительно рекомендуется выключить буферизацию функцией setvbuf(3C), тогда каждый вызов fwrite будет вызывать соответствующий системный вызов лишь после небольшого количества проверок.

Более сложный вопрос – зачем это было сделано. Ответ, скорее всего, состоит в том, что функции буферизованного ввода-вывода – не просто «обертки» над соответствующими системными вызовами, они осуществляют определенные (и иногда довольно сложные) операции над структурой данных, которая, собственно, и является буфером ввода-вывода. Прерывание этих библиотечных функций в неудачный момент либо приводило бы к риску оставить буфер ввода-вывода в несогласованном состоянии, либо требовало бы сложных вычислений для отслеживания и восстановления его согласованности.