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

Цилюрик Олег Иванович

sigqueue(pid, i, value);

cout << "signal sent: " << i << " with val = " << j << endl;

}

}

cout << "PARENT: finished!' << endl;

exit(EXIT_SUCCESS);

}

Идея этого теста крайне проста:

• Создаются два процесса, один из которых (родительский) посылает серию последовательных (по номерам) сигналов, а второй (дочерний) должен их принять и обработать.

•

Начальный и конечный номера сигналов в серии могут быть переопределены ключами

– b

и

– е

соответственно.

• Посылается не одиночный сигнал, а их повторяющаяся группа; размер группы повторений может быть переопределен ключом -

n

.

• В качестве значения, передаваемого с каждым сигналом, устанавливается последовательный номер его посылки в группе.

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

pidin

посмотрим его состояние:

1077295 1 ./s5 10r NANOSLEEP

1081392 1 ./s5 10r NANOSLEEP

Это то, что мы и предполагали получить. Рассмотрим теперь результат выполнения приложения со значениями сигналов по умолчанию (сигналы 56...54, именно в порядке убывания, в каждой группе посылается 3 сигнала):

# ./s5

signal SIGRTMIN=41 - signal SIGRTMAX=56

CHILD: signal mask set

signal sent: 56 with val = 0

signal sent: 56 with val = 1

signal sent: 56 with val = 2

signal sent: 55 with val = 0

signal sent: 55 with val = 1

signal sent: 55 with val = 2

signal sent: 54 with val = 0

signal sent: 54 with val = 1

signal sent: 54 with val = 2

PARENT: finished!

# CHILD: signal unblock

received signal 56 code = -2 val = 0

received signal 56 code = -2 val = 1

received signal 56 code = -2 val = 2

received signal 55 code = -2 val = 0

received signal 55 code = -2 val = 1

received signal 55 code = -2 val = 2

received signal 54 code = -2 val = 0

received signal 54 code = -2 val = 1

received signal 54 code = -2 val = 2

Первый сюрприз, который нас ожидает, — это общее количество сигналов реального времени, выводимое программой в первой строке. Документация (HELP QNX) утверждает:

There are 24 POSIX 1003.1b realtime signals, including:

SIGRTMIN — First realtime signal.

SIGRTMAX — Last realtime signal.

Здесь есть некоторое несоответствие: тест дает значения констант

SIGRTMIN

= 41 и

SIGRTMAX

= 56, а общее количество сигналов = 16 (POSIX,

как вы помните, требует минимум 8). «Потерявшиеся» сигналы (24 – 16 = 8), очевидно, и есть те сигналы из диапазона 32…40, которые выходят за пределы общих UNIX-сигналов (1…31), но не отнесены к диапазону сигналов реального времени (41…56).

Но гораздо больший сюрприз состоит в порядке доставки сигналов из очереди FIFO принимающему процессу. Документация об этом сообщает (выделено нами):

The POSIX standard includes the concept of queued realtime signals. QNX Neutrino supports optional queuing of any signal, not just realtime signals. The queuing can be specified on a signal-by-signal basis within a process. Each signal can have an associated 8-bit code and a 32-bit value.

This is very similar to message pulses described earlier. The kernel takes advantage of this similarity and uses common code for managing both signals and pulses. The signal number is mapped to a pulse priority using SIGMAX — signo. As a result, signals are delivered in priority order with lower signal numbers having higher priority. This conforms with the POSIX standard, which states that existing signals have priority over the new realtime signals.

Изменим временной порядок возбуждения сигналов - от сигналов с меньшими номерами к сигналам с большими номерами:

# ./s5 -b54 -e56 -n2

signal SIGRTMIN=41 - signal SIGRTMAX=56

CHILD: signal mask set

signal sent: 54 with val = 0

signal sent: 54 with val = 1

signal sent: 55 with val = 0

signal sent: 55 with val = 1

signal sent: 56 with val = 0

signal sent: 56 with val = 1

PARENT: finished!

# CHILD: signal unblock

received signal 56 code = -2 val = 0

received signal 56 code = -2 val = 1

received signal 55 code = -2 val = 0

received signal 55 code = -2 val = 1

received signal 54 code = -2 val = 0

received signal 54 code = -2 val = 1

Независимо от порядка отправки сигналов порядок доставки их из очереди принимающему процессу сохраняется от старших номеров сигналов, которые являются более приоритетными, к младшим. А это в точности противоположно тому, что обещает документация, и соответствует картине, которую У. Стивенс наблюдал в ОС Sun Solaris 2.6 и которую он же комментирует словами: «Похоже, что в реализации Solaris 2.6 есть ошибка».

Выполним ту же задачу, но теперь не относительно сигналов диапазона реального времени, а относительно стандартных UNIX-сигналов. Выберем для этого произвольный диапазон сигналов (

<signal.h>

):

#define SIGVTALRM 28 /* virtual timer expired */

#define SIGPROF 29 /* profiling timer expired */

#define SIGXCPU 30 /* exceeded cpu limit */

#define SIGXFSZ 31 /* exceeded file size limit */