QNX/UNIX: Анатомия параллелизма

Цилюрик Олег Иванович

void* threadfunc(void* data) {

int res; // результат некоторых вычислений

res = ...

pthread_exit(&res);

}

А вот один из многих допустимых вариантов:

void* threadfunc(void* data) {

struct data *res = new struct; // результат некоторых вычислений

...

*res = ...

pthread_exit(res);

}

...

pthread_t tid;

pthread_create(&tid, NULL, threadfunc, NULL);

struct data *res;

pthread_join(tid, &res);

...

delete res;

Недостатком

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

Уничтожение (отмена) потока

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

Если для процесса в перечень «опасных» (с точки зрения завершения) объектов включаются только объекты со временем жизни выше уровня процесса (их число достаточно ограничено), то для потока в число таких объектов включаются уже все объекты со временем жизни процесса (process-persistent). Завершающийся (покидающий процесс) поток обязан оставить все объекты процесса в состоянии, пригодном для их дальнейшего использования другими потоками процесса.

Далее мы подробно рассмотрим то множество предосторожностей, которыми «обложена» отмена потока. Однако именно по причине их «множества» стоит сформулировать краткое правило: не пытайтесь завершать поток извне его функции потока, если для этого нет в высшей степени обоснованной необходимости (а такая необходимость действительно бывает, но крайне редко). Даже в крайнем случае следует рассмотреть возможность вместо отмены потока послать ему сигнал (даже не только «сигнал UNIX», а в более широком смысле — «некоторое сообщение»), который, обрабатываясь в контексте потока, после корректных завершающих действий вызовет его завершение. (Как обращаться с сигналами в потоке, будет детально рассмотрено позже.)

Для отмены (принудительного завершения) потока используется вызов:

int pthread_cancel(pthread_t thread);

где в качестве параметра thread указывается TID отменяемого потока. Однако этот вызов не отменяет поток, а только запрашивает завершение потока. В зависимости от статуса отмены, который мы сейчас рассмотрим, поток может перейти (или нет) к действию завершения, которое состоит в том, что:

• выполняются все процедуры завершения, занесенные ранее в стек завершения вызовами

pthread_cleanup_push

;

• выполняются деструкторы собственных данных потока;

• отменяемый поток завершается;

• процесс отмены — асинхронный с точки зрения вызывающего

pthread_cancel

кода, поэтому вызывающий отмену поток должен дождаться завершения потока на вызове

pthread_join

.

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

int pthread_setcancelstate(int state, int* oldstate);

где

state

и

oldstate

— устанавливаемое и установленное ранее (возвращаемое вызовом) состояния отмены потока, которые могут принимать значения

PTHREAD_CANCEL_DISABLE

либо

PTHREAD_CANCEL_ENABLE

. (Естественно, как и во многих функциях с подобным прототипом, значением

oldstate

может быть

NULL

, и тогда нам не нужно возвращать ранее установленное состояние.)

Далее, даже если для потока установлено состояниезавершаемости (также называемое «состоянием отмены»)

PTHREAD_CANCEL_ENABLE

(это значение по умолчанию при создании потока), поток может переопределить еще и типотмены, вызвав:

int pthread_setcanceltype(int type, int* oldtype);

где

type

и

oldtype

— как и в предыдущем случае, новое и ранее установленное значения типа отмены потока, которые могут принимать значения

PTHREAD_CANCEL_ASYNCHRONOUS

(асинхронный по отмене поток) либо

PTHREAD_CANCEL_DEFERRED

(синхронный по отмене поток). Значением по умолчанию, устанавливаемым при создании потока, является

PTHREAD_CANCEL_DEFERRED

, хотя предписываемым POSIX умолчанием является

PTHREAD

_CANCEL_ASYNCHRONOUS.

Обе рассмотренные функции установок [23] параметров отмены при успешном выполнении возвращают значение EOK.

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

Теперь о том, чем же отличается отмена асинхронно и синхронно завершаемых потоков. Поток с асинхронным типом отмены (установленный с

PTHREAD_CANCEL_ASYNCHRONOUS

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

PTHREAD_CANCEL_DEFERRED

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

pthread_cancel

) запрос помещается в очередь, а процесс отмены активизируется только после того, как отменяемый поток в ходе своего выполнения достигнет очередной точки отмены. Как определяются (создаются) точки отмены в коде потока? Для этого служит функция:

23

Согласно стандарту POSIX установки состояния и типа завершаемости могут быть сделаны только из уже выполняющегося кода потока (при старте потока эти параметры установлены в значения по умолчанию). QNX делает расширение, позволяя установить соответствующие флаги в атрибутной записи еще до создания потока. Подробнее об этом говорилось при обсуждении создания потока.

void pthread_testcancel(void);

Каждый вызов

pthread_testcancel

тестирует очередь поступивших запросов на отмену на предмет наличия запросов, и если таковой запрос есть, процесс отмены активизируется. Если в коде отсутствуют вызовы

pthread_testcancel

, то в нем практически отсутствуют точки отмены и поток становится неотменяемым (подобно установке его состояния отмены в

PTHREAD_CANCEL_DISABLE

). Поэтому при выполнении длительных вычислений функцию

pthread_testcancel

следует периодически вызывать в потоковой функции в тех точках, где потенциальная отмена потока не опасна.

Примечание

( Очень важно!) Достаточно много библиотечных функций могут сами устанавливать точки отмены. Более того, такие функции могут косвенно вызываться из других функций в программе и тем самым неявно устанавливать точки отмены. Информацию о таких функциях следует искать в справочной man-странице по функции

pthread_testcancel

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

pthread_testcancel

, а ранее этой точки — когда будет вызвана одна из таких функций. А это, очевидно, вовсе не то, на что вы рассчитывали!