Системные вызовы

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

• процесс dipcd не выполняется;
• данная машина действительно является владельцем;
• запрашиваемая команда не поддерживается DIPC при удаленном исполнении - например, SHM_UNLOCK - при использовании shmctl();
• процесс, сделавший вызов, не относится к dipcd.

На следующей схеме показано ``прохождение'' пользовательского системного вызова DIPC (например, msgsnd()), обрабатываемого с помощью RPC.

Сеть (Вызывающий компьютер) | (Компьютер-владелец) | |-1->back_end>--2-+ | | | | | | ядро |<----------9--employer --3-------|->front_end--4-->worker -5->| ядро | | | | | | +-8-<front_end<-|------------7-----+ +-6----<|

Здесь back_end отыскивает запросы в ядре (1), причем, адрес машины-владельца должен быть однозначно определен на уровне ядра. Затем back_end раздваивает процесс employer для обработки запроса (2); employer подключается к front_end на машине-владельце (3). После чего front_end раздвоит worker (4), который непосредственно исполнит системный вызов (5) и соберет все результаты (6). Результаты посылаются назад front_end на вызывающий компьютер (7), который передает их оригинальному employer (8). Наконец, employer отдаст результаты ядру (9), откуда пользовательский процесс и получит их.

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

Ошибки, обнаруженные при работе back_end и employer, в виде соответствующего результирующего сообщения об ошибке передаются ядру. При других обстоятельствах ошибки игнорируются и только результирующие сообщения об ошибках выводятся процессами dipcd, которые столкнулись с ними. Только после наступления тайм-аута employer проинформирует об этом ядро.

Далее перечислены поддерживаемые системные вызовы:

1. msgctl(), msgsnd(), msgrcv(), semctl(), semop() и
   shmctl(). Они исполняются непосредственно на машине - владельце, что осуществляется с помощью RPC. Эти вызовы перехватываются на уровне ядра, а все требующиеся параметры и данные копируются в память ядра.

   Выше было показано, что может выполняться достаточно большое число операций копирования между ядром и пользовательским пространством при одном удаленном системном вызове. Это сильно снижает производительность, особенно, когда копируются большие блоки данных. К счастью, большинство системных вызовов IPC System V передают данные только в одном направлении. Например, msgrcv() только принимает данные, поэтому они копируются из оригинальной задачи в ядро с небольшими затратами. Кроме того, многие другие системные вызовы IPC имеют немного байтов данных, являющихся их параметрами. Одним из примеров может быть xxxctl() с флагом IPC_RMID. Издержки копирования необходимых данных и результатов, даже с учетом задействования сети, незначительны.

   Результатом системных вызовов xxxctl() вследствие команды IPC_RMID на машине - владельце, в успешном случае, будет взаимодействие с referee.

2. shmget(), semget() и msgget(). Эти вызовы привлекают
   referee, но не ядро машины-владельца (если системный вызов делается на машине-владельце!).

3. shmat(). Он выполняется локально.

4. shmdt(). Если реализуется удаление сегмента разделяемой памяти, то в результате он будет взаимодействовать с referee.