- •Краткая история создания ms-dos
- •Архитектура операционной системы
- •1.7. Эффективность и требования, предъявляемые к ос
- •Операционная система qnx
- •10.1. Архитектура
- •10.2. Управление процессами
- •10.3. Средства взаимодействия
- •10.4. Файловая система
- •10.5. Управление устройствами
- •10.6. Сетевые взаимодействия
- •10.7. Графическая система Photon
- •Прогон программы создания процесса
- •Области виртуальной памяти
- •Структура vm_area_struct
- •Современные файловые системы: что выбрать для внешнего накопителя и почему
- •Fat32 — разумный компромисс между совместимостью и прочими характеристиками
- •Ntfs — быстрая, мощная, но избыточная
- •ExFat — будущее флэш-накопителей и не только
- •Прочая экзотика, иногда полезная
- •Faq вместо заключения
10.3. Средства взаимодействия
ОС QNX обеспечивает (на уровне микроядра) три средства взаимодействия процессов: сигналы, сообщения и поручения (proxy).
Механизм сигналов соответствует тому, который мы рассмотрели в разделе 9.2 части I. QNX работает с большим количеством типов сигналов, среди которых:
стандартные сигналы, определяемые POSIX;
сигналы, управляющие работой процессов;
специальные сигналы QNX;
сигналы, поддерживающие старые версии Unix.
Процесс может определять способы обработки некоторых (но не всех) сигналов.
Сообщения являются основным способом взаимодействия между процессами в QNX. В отличие от того смысла, который мы вкладывали в этот термин в разделе 9.7 части I, в QNX сообщения являются синхронными, то есть процесс, пославший сообщение, требует обязательного ответа на него.
Обмен сообщениями обеспечиваются вызовами микроядра:
Send() - посылка сообщения:
Recive() - прием сообщения;
Reply() - посылка ответа.
На рисунке 10.2 показан сценарий взаимодействия процессов при посылке сообщения
|
В соответствии с протоколом передачи сообщений различаются следующие подвиды блокировки процесса:
SEND-блокированный процесс - послал сообщение и ожидает подтверждения его приема.
REPLY-блокированный процесс - получил подтверждение приема и ожидает получения ответа.
RECIVE-блокированный процесс - запросил прием сообщения и ожидает его поступления. На рисунке 10.2 состояние RECIVE-блокировки не показано, в него мог бы попасть Процесс B, если бы выполнил системный вызов Recive() прежде, чем Процесс A выполнил Send().
Модель сообщений QNX более всего напоминает взаимодействие процессов по принципу рандеву (см. раздел 8.11 части I), описываемую как:
A!x; ?y
Для взаимодействия процессов необходима "встреча" готовности одного процесса (Процесса A) передать сообщение и готовности другого процесса (Процесса B) принять сообщение. При этом для процессов, участвующих в рандеву, нет необходимости знать о готовности процесса-корреспондента. Процесс, первым пришедший в точку рандеву, просто блокируется (SEND- или RECIVE-блокировкой) до готовности процесса-партнера.
Передача ответа подтверждения не требует, и выполнение вызова Reply() не приводит к блокировке процесса, выполнившего этот вызов.
При необходимости процесс может посылать сообщения нулевой длины и/или ответы нулевой длины - такие приемы применяются для взаимного исключения и синхронизации без обмена данными.
Несколько процессов могут послать сообщения одновременно одному адресату. В этом случае сообщения могут обрабатываться (получаться адресатом) либо в порядке их поступления, либо в соответствии с приоритетами отправителей.
Еще один вызов микроядра -Crecive() - позволяет процессу проверить наличие сообщений для него и, таким образом, избежать RECIVE-блокировки.
Интересно, что, используя механизм сообщений-рандеву, библиотеки системных вызовов QNX обеспечивают интерфейсы других стандартных средств взаимодействия процессов, таких как программные каналы или семафоры.
Третий вид взаимодействия - поручения - обеспечивает асинхронное взаимодействие процессов. Фактически поручения идентичны очередям сообщений, описанным нами в разделе 9.7 части I.

Рисунок
10.2 Сценарий взаимодействия процессов
при посылке сообщения