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

Примечание

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

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

Барьер

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

static pthread_barrier_t bfinish;

void* threadfunc(void* data) {

 // потоки что-то делают ...

 pthread_barrier_wait(&bfinish);

 return NULL;

}

int main(int argc, char *argv[]) {

 int N = ...; // будем создавать N идентичных потоков

 if (pthread_barrier_init(&bfinish, NULL, N + 1) != EOK)

  perror("barrier init"), exit(EXIT.FAILURE);

 for (int i = 0; i < N; i++)

  if (pthread_create(NULL, NULL, threadfunc, NULL) != EOK)

   perror("thread create"), exit(EXIT_FAILURE);

 pthread_barrier_wait(&bfinish);

}

Очевидно, что по функциональности эта схема мало отличается от ожидания завершения потоков на pthread_join, описанного выше. Однако есть различия в организации: если ранее мы просто ожидали полного завершения дочерних потоков, то в данной схеме мы ожидаем достижения ими специально созданной точки синхронизации. Еще одно отличие состоит в том, что схема синхронизации с ожиданием завершения на pthread_joinприемлема только для «присоединенных» потоков, тогда как схема на pthread_barrier_waitможет применяться и к «отсоединенным», автономным потокам.

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

static pthread_barrier_t bstart;

void* threadfunc(void* data) {

 // все потоки после создания должны "застрять" на входном барьере,

 // чтобы потом одновременно "сорваться" в исполнение...

 pthread_barrier_wait(&bstart);

 // ... выполнение ...

 return NULL;

}

int main(int argc, char *argv[]) {

 ...

 int N = ...; // будем создавать N идентичных потоков

 if (pthread_barrier_init(&bstart, NULL, N) != EOK)

  perror("barrier init"), exit(EXIT_FAILURE);

 for (int i = 0; i < nthr; i++) {

  if (pthread_create(NULL, NULL, threadfunc, NULL) != EOK)

  perror("thread create"), exit(EXIT_FAILURE);

 }

 ...

}

Обратите внимание на параметр количества ожидающих на барьере потоков при его инициализации: здесь он на единицу меньше.

Применение барьеров подробно описано в литературе [1], поэтому мы не будем специально останавливаться на этом элементе синхронизации, тем более что это один из наиболее простых в применении элементов.

По непонятным причинам документация QNX [8] причисляет барьеры к элементам синхронизации ядра, однако никаких средств native API QNX, предназначенных для работы с барьерами, документация не описывает, а заголовочный файл так описывает тип pthread_barrier_t: