Очевидно, что по функциональности эта схема мало отличается от ожидания завершения потоков на 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:

typedef struct {

 unsigned int barrier;

 unsigned int count;

 pthread_mutex_t lock;

 pthread_cond_t bcond;

} pthread_barrier_t;

Выводы можно сделать самостоятельно.

Также несколько загадочно выглядит тот факт, что согласно документации QNX 6.2.1 все функции работы с барьером и его атрибутами описаны в заголовочном файле , за исключением двух функций pthread_barrier_wait() и pthread_barrierattr_setpshared(), о которых говорится, что они описаны в файле ! Но если заглянуть в заголовочные файлы, то выясняется, что можно спокойно использовать для абсолютно всех функций работы с барьером либо заголовочный файл , либо .

Операции с барьерами

Параметры барьера

Следующие функции инициализируют и разрушают блок параметров барьера:

int pthread_barrierattr_init(pthread_barrierattr_t* attr);

int pthread_barrierattr_destroy(pthread_barrierattr_t* attr);

Функция инициализации возвращает следующие значения:

EOK — успешное выполнение;

ENOMEM — недостаточно памяти для инициализации атрибутов барьера.

Функция разрушения атрибутов объекта возвращает значения:

EOK — успешное выполнение;

EINVAL — передан неверный объект атрибутов барьера attr.

Параметры барьера описываются типом pthread_barrierattr_t и аналогично другим типам синхронизации используются в момент инициализации элемента синхронизации. Фактически единственным атрибутом барьера является модификатор доступа к барьеру из других процессов:

int pthread_barrierattr_setpshared(

pthread_barrierattr_t* attr, int pshared);

int pthread_barrierattr_getpshared(

const pthread_barrierattr_t* attr, int* pshared);

По умолчанию атрибуты барьера запрещают доступ к элементу синхронизации из других процессов.

Обе функции могут возвращать следующие значения: