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

 volatile unsigned ind = 0;
 ...
 // а вот это производится из каждого потока
 char tbuf[M];
 sprintf(tbuf, "Это вывод потока %X", pthread_self);
 strcpy(buf + atomic_add_value(ind, strlen(tbuf)), tbuf);

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

Сравнение мьютекса и двух форм вызова атомарной операции

 #include <stdlib.h>
 #include <stdio.h>
 #include <iostream.h>
 #include <unistd.h>
 #include <inttypes.h>
 #include <pthread.h>
 #include <sys/neutrino.h>
 #include <atomic.h>

 int main(int argc, char *argv[]) {
  uint64_t N = 100000;
  bool atom = false, value = false;
  int opt, val;
  while ((opt = getopt(argc, argv, "n:av")) != -1) {
  switch(opt) {
  case 'n': // количество повторений
  if (sscanf(optarg, "%i", &val) != 1)
  cout << "parse command line error" << endl, exit(EXIT_FAILURE);
  if (val > 0) N = val;
  break;
  // использовать атомарные операции
  case 'a':
  atom = true;
  break;
  // использовать форму, возвращающую значение
  case 'v':
  value = true;
  break;
  default:
  exit(EXIT_FAILURE);
  }
  }
  // замеряется количество процессорных циклов для каждого случая
  uint64_t i = N, t = ClockCycles;
  volatile unsigned ind = 0;
  if (!atom) {
  pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
  while (i--) {
  pthread_mutex_lock(&mutex);
  ind++;
  pthread_mutex_unlock(&mutex);
  }
  } else if (value)
  while (i--) atomic_add_value(&ind, 1);
  else while (i--) atomic_add(&ind, 1);
  t = ClockCycles - t;
  cout << "all cycles - " << t << "; on operation - "
  << t / N << endl;
  exit(EXIT_SUCCESS);
 }

Вот результат при использовании критической секции:

 # nice -n-19 a1 -n10000000
 all cycles - 1120872156; on operation - 112

Результат с применением атомарной операции, не возвращающей значения:

 # nice -n-19 a1 -n10000000 -a
 all cycles — 391018203; on operation - 39

Результат с применением атомарной операции, возвращающей значение (обещанная разница составляет порядка 10%):

 # nice -n-19 a1 -n10000000 -a -v
 all cycles - 441158981; on operation - 44

Условная переменная

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

Реализация подобного ожидания «в лоб» привела бы к тому, что все потоки, разделяющие данную критическую секцию, были бы вынуждены ждать выполнения условия для каждого из них. При «правильной» реализации ожидания поток должен освобождать мьютекс на время ожидания и вновь захватывать его, когда ожидаемое условие выполняется. Специально для этого случая стандартом POSIX предусмотрены условные переменные. QNX Neutrino реализует условные переменные как на уровне вызовов микроядра в своем native API, так и в соответствии со стандартом POSIX.

Отметим, что дополнение мьютекса условной переменной делает их комбинацию универсальным базисом, на котором могут быть построены любые сколь угодно сложные в своем поведении объекты синхронизации.

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

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

Рис. 4.1. Схема действий потока при выполнении синхронизации с применением пары мьютекс-условная переменная (обратите внимание, что операции при участии мьютекса (1, 2, 3) выполняются дважды.)

Проблема в первую очередь заключается в том, что внутри критической секции, отмеченной вызовами функций pthread_mutex_lock и pthread_mutex_unlock, не может находиться более одного потока в единый момент времени. Следовательно, даже если поток, блокированный на условной переменной, и получит pthread_cond_signal или pthread_cond_broadcast, он не сможет немедленно продолжить свое выполнение, если внутри критической секции уже находится другой поток. В этом случае разблокированный (на условной переменной) поток изменяет свой статус с «блокированного на условной переменной» (в котором он находился до этого) на статус «блокированного на мьютексе» и пребывает в нем до тех пор, пока текущий владелец не освободит мьютекс.