UNIX: взаимодействие процессов

37    printf("minimum size of shared memory segment = %lu\n", size);

38    Shmctl(shmid[0], IPC_RMID, NULL);

39    break;

40   }

41  }

42  /* определение максимального размера сегмента */

43  for (size = 65536; ; size += 4096) {

44   shmid[0] = shmget(IPC_PRIVATE, size, SVSHM_MODE | IPC_CREAT);

45   if (shmid[0] == –1) { /* выход при ошибке */

46    printf("maximum size of shared memory segment = %lu\n", size-4096);

47    break;

48   }

49   Shmctl(shmid[0], IPC_RMID, NULL);

50  }

51  exit(0);

52 }

Запустив эту программу в Digital Unix 4.0B, увидим:

alpha % limits

127 identifiers open at once

32 shared memory segments attached at once

minimum size of shared memory segment = 1

maximum size of shared memory segment = 4194304

Причина, по которой в табл. 14.1 приведено значение 128 для числа идентификаторов, а наша программа выводит значение 127, заключается в том, что один сегмент разделяемой памяти всегда используется системным демоном.

14.8. Резюме

Разделяемая память System V похожа на разделяемую память Posix. Наиболее схожи функции:

■ shmget для получения идентификатора; 

■ shmat для подключения сегмента разделяемой памяти к адресному пространству процесса;

■ shmctl с командой IPC_STAT для получения размера существующего сегмента разделяемой памяти;

■ shmctl с командой IPC_RMID для удаления объекта разделяемой памяти.

Одно из отличий состоит в том, что размер объекта разделяемой памяти Posix может быть изменен в любой момент вызовом ftruncate (как мы продемонстрировали в упражнении 13.1), тогда как размер объекта разделяемой памяти System V устанавливается изначально вызовом shmget и не может быть изменен.

Упражнение

Листинг 6.6 содержал измененную версию программы из листинга 6.4. Новая программа использовала для обращения к объекту IPC System V идентификатор вместо полного имени. Таким образом мы показали, что для доступа к очереди сообщений System V достаточно знать только ее идентификатор (если у нас имеются соответствующие разрешения). Сделайте аналогичные изменения в программе из листинга 14.4, продемонстрировав, что это верно и для разделяемой памяти System V. 

ЧАСТЬ 5 УДАЛЕННЫЙ ВЫЗОВ ПРОЦЕДУР

ГЛАВА 15 Двери

15.1. Введение

Поговорим о схеме клиент-сервер и вызове процедур. Существуют три различных типа вызова процедур, показанные на рис. 15.1.

Рис. 15.1. Три типа вызова процедур

1. Локальный вызов процедуры (local procedure call) знаком нам по обычному программированию на языке С. Вызываемая и вызывающая процедуры (функции) при этом относятся к одному и тому же процессу. При этом обычно выполняется некая команда процессора, передающая управление новой процедуре, а вызвавшая процедура сохраняет значение регистров процессора и выделяет место в стеке Под свои локальные переменные.

2. Удаленный вызов процедуры (remote procedure call — RPC) происходит в ситуации, когда вызвавшая и вызываемая процедуры относятся к разным процессам. В такой ситуации мы обычно называем вызвавшую процедуру клиентом, а вызванную — сервером. Во втором сценарии на рис. 15.1 клиент и сервер выполняются на одном и том же узле. Это типичный частный случай третьего сценария, и это именно то, что осуществляется с помощью дверей (doors). Итак, двери дают возможность вызывать процедуру (функцию) другого процесса на том же узле. Один из процессов (сервер) делает процедуру, находящуюся внутри него, доступной для вызова другим процессам (клиентам), создавая для этой процедуры дверь. Мы можем считать двери специальным типом IPC, поскольку при этом между процессами (клиентом и сервером) передается информация в форме аргументов функции и возвращаемых значений.

3. RPC в общем случае дает возможность клиенту на одном узле вызвать процедуру сервера на другом узле, если эти два узла связаны каким-либо образом по сети (третий сценарий на рис. 15.1). Такой вид взаимодействия будет описан в главе 16.