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

  }
  }
  // установка сигнальных обработчиков
  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 — именно такая система) эта сторона вопроса не может игнорироваться, и не только потому, что потоки в комбинации с сигналами могут создавать мощные конструктивные элементы программ, а еще и потому, что непроизвольные разблокирующие или завершающие операции, инициируемые сигналами, могут породить очень серьезные проблемы в случае многопоточности (мы еще будем возвращаться к этим вопросам по тексту). А раз так, то в этих случаях система должна обязательно предлагать некоторую модель функционирования (удачную или не очень).

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

The original POSIX specification defined signal operation on processes only. In a multi-threaded process, the following rules are followed:

*The signal actions are maintained at the process level. If a thread ignores or catches a signal, it affects all threads within the process.

*The signal mask is maintained at the thread level. If a thread blocks a signal, it affects only that thread.

*An un-ignored signal targeted at a thread will be delivered to that thread alone.

*An un-ignored signal targeted at a process is delivered to the first thread that doesn't have the signal blocked. If all threads have the signal blocked, the signal will be queued on the process until any thread ignores or unblocks the signal. If ignored, the signal on the process will be removed. If unblocked, the signal will be moved from the process to the thread that unblocked it.

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

Для манипулирования сигнальными масками на уровне потоков нам придется использовать функцию SignalProcmask [34] (естественно, из состава native API, поскольку эта модель не декларирована POSIX):

 #include <sys/neutrino.h>
 int SignalProcmask(pid_t pid, int tid, int how, const sigset_t* set,

34

Функция SignalProcmask имеет свой реентерабельный (безопасный в потоках) эквивалент: SignalProcmask_r.