Читать онлайн «QNX/UNIX: Анатомия параллелизма». Страница 41

  pthread_mutex_unlock(&_mutex);

 }

 T pop() {

  data_event.wait();

  pthread_mutex_lock(&_mutex);

  T res = data_queue.front();

  data_queue.pop();

  pthread_mutex_unlock(&_mutex);

  return res;

 }

private:

 std::queue<T> data_queue;

 event data_event;

 pthread_mutex_t _mutex;

};

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

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

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

Для проведения таких оценок используем уже применявшуюся нами схему «симметричных» тестов. Почему именно их? Да, здесь нам не требуются в явном виде обменные операции потоков, но воспользуемся «симметричными» тестами просто в силу минимальных переделок того, что уже было написано ранее. Итак, первый вариант теста для мьютекса (файл sy20m.cc):

unsigned long N = 1000;

static pthread_barrier_t bstart;

static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;

static bool debug = false;

static char* str;

static volatile int ind = 0;

void* threadfunc(void* data) {

 pthread_barrier_wait(&bstart);

 unsigned long i = 0;

 char tid[8];

 sprintf(tid, "%d", pthread_self());

 uint64_t t = 0, t1;

 while (i++ != N) {

  t1 = ClockCycles();

  pthread_mutex_lock(&mutex);

  if (debug) str[ind++] = *tid;

  pthread_mutex_unlock(&mutex);

  t += ClockCycles() - t1;

  sched_yield();

 }

 cout << pthread_self() << "\t: cycles - "

  << t << ", on mutex - " << t / N << endl;

 return NULL;

}

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

 int opt, val;

 while ((opt = getopt(argc, argv, "n,v")) != -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 'v':

   debug = true;

   break;

  default:

   exit(EXIT_FAILURE);

  }

 }

 if (debug) str = new char[2 * N + 1];

 const int T = 2;

 pthread_t tid[T];

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

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

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

  if (pthread_create(tid + i, NULL, threadfunc, NULL) != EOK)

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

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

  pthread_join(tid[i], NULL);

 if (debug) {

  str[ind] = '\0';

  cout << str << endl;

  delete [] str;

 }

 exit(EXIT_SUCCESS);

}

Результаты выполнения этого теста:

# sy20m -n100000

3       : cycles - 14644442, on mutex - 146

2       : cycles - 14614219; on mutex - 146

# sy20m -n1000000

3       : cycles - 146505047; on mutex - 146

2       : cycles - 146388673; on mutex - 146

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

1. Вместо мьютекса объявляем неименованный семафор, а статическая инициализация мьютекса заменяется на оператор (в теле главной программы) динамической инициализации семафора с присвоением ему начального значения 1:

static sem_t sem;

...

if (sem_init(&sem, 0, 1) != 0)

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

2. Функция потока принимает вид:

void* threadfunc(void* data) {

 ...

 while (i++ != N) {

  t1 = ClockCycles();

  sem_wait(&sem);

  if (debug) str[ind++] = *tid;

  sem_post(&sem);

  t += ClockCycles() - t1;

  sched_yield();

 }

 ...

}

В результате исполнения на этот раз мы получим:

# sy20s -n100000

3       : cycles - 87048886; on semaphore - 870

2       : cycles - 87077787; on semaphore - 870

# sy20s -n1000000

3       : cycles - 869638168; on semaphore — 869

2       : cycles - 868725494, on semaphore - 868

Делаем последнюю модификацию в этой группе тестов, теперь используем специфику именованного семафора (файл sy20n.cc):

1. Вместо оператора динамической инициализации неименованного семафора мы теперь должны создать именованный семафор:

static sem_t* sem;

...

const char semname[] = "/duble";

if ((sem = sem_open(semname, O_CREAT, S_IRWX0, 1)) == SEM_FAILED)

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

Последний оператор заслуживает отдельного комментария. Техническая документация утверждает, что функция sem_open(), нормально возвращающая указатель созданного дескриптора семафора типа sem_t, в случае ошибки возвращает -1 (так было записано и в самых ранних редакциях POSIX). Но использование конструкции вида:

if (sem_open( ... ) == -1)

просто вызовет синтаксическую ошибку (несоответствие типов) и не пройдет компиляцию! Естественнее было бы для такой функции возвращать NULL в случае ошибки, но... так определено в POSIX. Кроме того, во многих реализациях UNIX определяется константа:

#define SEM_FAILED ((sem_t*)(-1))

В документации QNX она нигде не упоминается, но, как мы видим, она определена, и все прекрасно работает!

2. Функция потока принимает вид (теперь sem, в отличие от предшествующего случая, ведь теперь это уже указатель на переменную типа sem_t):

void* threadfunc(void* data) {

 ...

 while (i++ != N) {

  t1 = ClockCycles();

  sem_wait(sem);

  if (debug) str[ind++] = *tid;

  sem_post(sem);

  t += ClockCycles() - t1;

  sched_yield();

 }

 ...

}

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

sem_close(sem);

sem_unlink(semname);

Запустим полученное приложение при таком значении -n, которое обеспечит достаточное время его работы. Прежде чем обсуждать полученные результаты, посмотрим отображение семафора на пространство файловых имен системы во время работы приложения:

# ls -l /dev/sem

total 1

n------r-х 1 root root 1 Feb 10 18.56 duble

А теперь и результаты работы программы:

# nice -n-19 sy20n -n100000

3      : cycles - 1453746002, on semaphore - 14537

2      : cycles - 1454203573, on semaphore - 14542

Наконец, мы можем обратиться к количественному анализу полученных цифр:

• Примитивы — мьютекс, неименованный и именованный семафоры, — кажущиеся на первый взгляд сходными, требуют для своего обслуживания в эквивалентных условиях принципиально различных затрат, величины которых радикально отличаются: 140 – 870 – 14500 процессорных циклов соответственно, что соотносится как 1:6,2:104.

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