QNX/UNIX: Анатомия параллелизма - Олег Цилюрик

Посмотрим также реакцию системы на специальные сигналы QNX, номера которых выше SIGRTMAX (в исследуемый диапазон опять для сравнения включим как специальные сигналы (57…64), так и сигналы из диапазона 1…SIGRTMAX):

# ./s5 -b56 -e59 -n2

signal SIGRTMIN=41 - signal SIGRTMAX=56

set signal handler... Invalid argument

set signal handler... Invalid argument

set signal handler... Invalid argument

CHILD: signal mask set

signal sent: 56 with val = 0

signal sent: 56 with val = 1

signal sent: 57 with val = 0

signal sent: 57 with val = 1

signal sent: 58 with val = 0

signal sent: 58 with val = 1

signal sent: 59 with val = 0

signal sent: 59 with val = 1

PARENT: finished!

# CHILD: signal unblock

received signal 56 code = -2 val = 0

received signal 56 code = -2 val = 1

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

Таким образом, система фактически никак не выделяет сигналы диапазона реального времени (41…56), но обрабатывает аналогичным образом и стандартные сигналы UNIX (1…31), и специальные сигналы QNX (57…64), и даже сигналы, никак не специфицируемые системой вообще (32…40). Корректнее говорить не об обработке сигналов реального времени и даже не о модели сигналов реального времени, а об еще одном способе работы с любыми сигналами - обработке сигналов на базе очередей сигналов.

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

typedef struct {

 int si_signo;

 int si_code; /* if SI_NOINFO, only si_signo is valid */

 int si_errno;

 union {

  int __pad[7];

  struct {

   pid_t __pid;

   union {

    struct {

     uid_t __uid;

     union sigval __value;

    } kill; /* si_code <= 0 SI_FROMUSER */

    struct {

     _CSTD clock_t __utime;

     /* CLD_EXITED status, else signo */

     int _status;

     _CSTD clock_t __stime;

    } __chld;

    /* si_signo=SlGCHLD si_code=CLD_* */

   } __pdata;

  } __proc;

  struct {

   int __fltno;

   void* __fltip;

   void* __addr;

  } fault; /* si_signo=SIGSEGV,ILL,FPE,TRAP,BUS */

 } __data;

} siginfo_t;

#define si_pid    __data.__proc.__pid

#define si_value  __data.__proc.__pdata.__kill.__value

#define si_uid    __data.__proc.__pdata.__kill.__uid

#define si_status __data.__proc.__pdata.__chld.__status

#define si_utime  __data.__proc.__pdata.__chld.__utime

#define si_stime  __data.__proc.__pdata.__chld.__stime

#define si_fltno  __data.__fault.__fltno

#define si_trapno si_fltno

#define si_addr   __data.__fault.__addr

#define si_fltip  __data.__fault.__fltip

И полный перечень определений символьных констант, используемых для установки значений поля si_code:

#define SI_USER      0

#define SI_RESERVED1 (-1)

#define SI_QUEUE     (-2)

#define SI_TIMER     (-3)

#define SI_ASYNCIO   (-4)

#define SI_MESGQ     (-5)

#define SI_NOTIFY    (-6)

#define SI_IRQ       (-7)

// QNX managers will never use this range.

#define SI_MINAVAIL  (-128)

#define SI_MAXAVAIL  (-64)

#define SI_NOINFO    127

#define SI_MAXSZ     126

Значение SI_QUEUE, равное -2, — это и есть то значение, которое мы видели в выводе тестовой задачи выше.

Соображения производительности

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

#include <stdlib.h>

#include <stdio.h>

#include <inttypes.h>

#include <iostream.h>

#include <unistd.h>

#include <sched.h>

#include <sys/neutrino.h>

// "пустые" обработчики сигналов

static void nhand(int signo) {}

static void qhand(int signo, siginfo_t* info, void* context) {}

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

 unsigned long N = 1000;

 bool que = false;

 int opt, val;

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

  // ключ q определяет схему обработки сигнала

  case 'q':

   que = true;

   break;

  default:

   exit(EXIT_FAILURE);

  }

 }

 // установка сигнальных обработчиков

 sigset_t sig;

 sigemptyset(&sig);

 sigaddset(&sig, SIGUSR1);

 sigprocmask(SIG_UNBLOCK, &sig, NULL);

 struct sigaction act;

 act.sa_mask = sig;

 act.sa_sigaction = qhand;

 act.sa_handler = nhand;

 act.sa_flags = que ? SA_SIGINFO : 0;

 if (sigaction(SIGUSR1, &act, NULL) < 0)

  cout << "set signal handler" << endl, exit(EXIT_FAILURE);

 pid_t pid = fork();

 if (pid == -1)

  cout << "fork error" << endl, exit(EXIT_FAILURE);

 // кому отправлять сигнал?

 pid_t did = (pid == 0 ? getppid() : pid);

 unsigned long i = 0;

 uint64_t t = ClockCycles();

 while (true) {

  kill(did, SIGUSR1);

  if (++i == N) break;

  pause();

 }

 t = ClockCycles() - t;

 cout << getpid() << " -> " << did << "t: cycles - " << t <<

  "; on signal - " << (t / N) / 2 << endl;

exit(EXIT_SUCCESS);

}

Этим приложением мы можем тестировать и традиционную схему обработки сигналов (модель надежных сигналов), и схему обработки с очередью поступления сигналов (модель сигналов реального времени), когда при старте программы указан ключ -q. Посмотрим на результаты тестовых запусков:

# nice -n-19 p6s -n1000

2904115 -> 2912308 : cycles - 5792027; on signal - 2896

2912308 -> 2904115 : cycles - 5828952; on signal — 2914

# nice -n-19 p6s -n10000

2920499 -> 2928692 : cycles - 57522753, on signal - 2876

2928692 -> 2920499 : cycles - 57530378; on signal - 2876

# nice -n-19 p6s -n100000

2936883 -> 2945076 : cycles - 573730469; on signal - 2868

2945076 -> 2936883 : cycles - 573738122; on signal - 2868

# nice -n-19 p6s -n1000000

2953267 -> 2961460 : cycles - 5747418203, on signal - 2873

2961460 -> 2953267 : cycles - 5747425310; on signal - 2873

Вспомним, что при изучении тестов простого переключения процессов (см. в главе 2) мы получали цифру порядка 600 процессорных циклов на переключение. Сейчас у нас затраты заметно больше: порядка 2850 циклов, из которых «лишние» 2250 — это не что иное, как затраты на посылку и прием сигнала, возбуждение функции обработчика и ее завершение (разделить их по компонентам мы не можем). Это и может служить ориентировочной оценкой трудоемкости обмена сигналами.

Проделаем то же самое, но уже при обработке сигналов в порядке очереди их поступления:

# nice -n-19 p6s -n1000 -q

2838579 -> 2846772 : cycles - 5772106; on signal - 2886

2846772 -> 2838579 : cycles - 5782138; on signal - 2891

# nice -n-19 p6s -n10000 -q

2854963 -> 2863156 : cycles - 57194634; on signal - 2859

2863156 -> 2854963 : cycles - 57199831; on signal - 2859

# nice -n-19 p6s -n1000000 -q

2871347 -> 2879540 : cycles - 571543013; on signal - 2857

2879540 -> 2871347 : cycles - 571550847; on signal - 2857

# nice -n-19 p6s -n1000000 -q

2887731 -> 2895924 : cycles - 5715903548; on signal - 2857

2895924 -> 2887731 : cycles - 5715908318; on signal - 2857

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

Сигналы в потоках

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