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

В системе UNIX имеется простейшая форма взаимодействия процессов, используемая в целях отладки, - трассировка процессов.

--------------------------------------------------------¬

¦ if ((pid = fork()) == 0) ¦

¦ { ¦

¦ /* потомок - трассируемый процесс */ ¦

¦ ptrace(0,0,0,0); ¦

¦ } ¦

¦ /* продолжение выполнения процесса-отладчика */ ¦

¦ for (;;) ¦

¦ { ¦

¦ wait((int *) 0); ¦

¦ read(входная информация для трассировки команд) ¦

¦ ptrace(cmd,pid,...); ¦

¦ break; ¦

¦ } ¦

L-------------------------------------------------------

Рисунок 11.1. Структура процесса отладки

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

Тем временем в обычной ситуации процесс-родитель (отладчик) переходит на пользовательский уровень, ожидая получения известия от трассируемого процесса. Когда соответствующее известие процессом-родителем будет получено, он выйдет из состояния ожидания (wait), прочитает (read) введенные пользователем команды и превратит их в серию обращений к функции ptrace, управляющих трассировкой процесса-потомка. Синтаксис вызова системной функции ptrace:

ptrace(cmd,pid,addr,data);

Если в момент перехода процесса-потомка в состояние трассировки отладчик не находится в состоянии приостанова (wait), он не обнаружит потомка, пока не обратится к функции wait, после чего немедленно выйдет из функции и продолжит работу по вышеописанному плану.

-------------------------------------------------------¬

¦ int data[32]; ¦

¦ main() ¦

¦ { ¦

¦ int i; ¦

¦ for (i = 0; i < 32; i++) ¦

¦ printf("data[%d] = %d\n@,i,data[i]); ¦

¦ printf("ptrace data addr Ox%x\n",data); ¦

¦ } ¦

L------------------------------------------------------

Рисунок 11.2. Программа trace (трассируемый процесс)

Рассмотрим две программы, приведенные на Рисунках 11.2 и 11.3 и именуемые trace и debug, соответственно. При запуске программы trace с терминала массив data будет содержать нулевые значения; процесс выводит адрес массива и завершает работу. При запуске программы debug с передачей ей в качестве параметра значения, выведенного программой trace, происходит следующее: программа запоминает значение параметра в переменной addr, создает новый процесс, с помощью функции ptrace подготавливающий себя к трассировке, и запускает программу trace. На выходе из функции exec ядро посылает процессу-потомку (назовем его тоже trace) сигнал SIGTRAP (сигнал прерывания),

-------------------------------------------------------------¬

¦ #define TR_SETUP 0 ¦

¦ #define TR_WRITE 5 ¦

¦ #define TR_RESUME 7 ¦

¦ int addr; ¦

¦ ¦

¦ main(argc,argv) ¦

¦ int argc; ¦

¦ char *argv[]; ¦

¦ { ¦

¦ int i,pid; ¦

¦ ¦

¦ sscanf(argv[1],"%x",&addr); ¦

¦ ¦

¦ if ((pid = fork() == 0) ¦

¦ { ¦

¦ ptrace(TR_SETUP,0,0,0); ¦

¦ execl("trace","trace",0); ¦

¦ exit(); ¦

¦ } ¦

¦ for (i = 0; i < 32, i++) ¦

¦ { ¦

¦ wait((int *) 0); ¦

¦ /* записать значение i в пространство процесса с ¦

¦ * идентификатором pid по адресу, содержащемуся в ¦

¦ * переменной addr */ ¦

¦ if (ptrace(TR_WRITE,pid,addr,i) == -1) ¦

¦ exit(); ¦

¦ addr += sizeof(int); ¦

¦ } ¦

¦ /* трассируемый процесс возобновляет выполнение */ ¦

¦ ptrace(TR_RESUME,pid,1,0); ¦

¦ } ¦

L------------------------------------------------------------

Рисунок 11.3. Программа debug (трассирующий процесс)

процесс trace переходит в состояние трассировки, ожидая поступления команды от программы debug. Если процесс, реализующий программу debug, находился в состоянии приостанова, связанного с выполнением функции wait, он "пробуждается", обнаруживает наличие порожденного трассируемого процесса и выходит из функции wait. Затем процесс debug вызывает функцию ptrace, записывает значение переменной цикла i в пространство данных процесса trace по адресу, содержащемуся в переменной addr, и увеличивает значение переменной addr; в программе trace переменная addr хранит адрес точки входа в массив data. Последнее обращение процесса debug к функции ptrace вызывает запуск программы trace, и в этот момент массив data содержит значения от 0 до 31. Отладчики, подобные sdb, имеют доступ к таблице идентификаторов трассируемого процесса, из которой они получают информацию об адресах данных, используемых в качестве параметров функции ptrace.

Использование функции ptrace для трассировки процессов является обычным делом, но оно имеет ряд недостатков.

Пакет IPC (interprocess communication) в версии V системы UNIX включает в себя три механизма. Механизм сообщений дает процессам возможность посылать другим процессам потоки сформатированных данных, механизм разделения памяти позволяет процессам совместно использовать отдельные части виртуального адресного пространства, а семафоры - синхронизировать свое выполнение с выполнением параллельных процессов. Несмотря на то, что они реализуются в виде отдельных блоков, им присущи общие свойства.

С сообщениями работают четыре системных функции: msgget, которая возвращает (и в некоторых случаях создает) дескриптор сообщения, определяющий очередь сообщений и используемый другими системными функциями, msgctl, которая устанавливает и возвращает связанные с дескриптором сообщений параметры или удаляет дескрипторы, msgsnd, которая посылает сообщение, и msgrcv, которая получает сообщение.

Синтаксис вызова системной функции msgget:

msgqid = msgget(key,flag);

где msgqid - возвращаемый функцией дескриптор, а key и flag имеют ту же семантику, что и в системной функции типа "get". Ядро хранит сообщения в связном списке (очереди), определяемом значением дескриптора, и использует значение msgqid в качестве указателя на массив заголовков очередей. Кроме вышеуказанных полей, описывающих общие для всего механизма права доступа, заголовок очереди содержит следующие поля:

Когда пользователь вызывает функцию msgget для того, чтобы создать новый дескриптор, ядро просматривает массив очередей сообщений в поисках существующей очереди с указанным идентификатором. Если такой очереди нет, ядро выделяет новую очередь, инициализирует ее и возвращает идентификатор пользователю. В противном случае ядро проверяет наличие необходимых прав доступа и завершает выполнение функции.

Для посылки сообщения процесс использует системную функцию msgsnd:

msgsnd(msgqid,msg,count,flag);

-------------------------------------------------------------¬

¦ алгоритм msgsnd /* послать сообщение */ ¦

¦ входная информация: (1) дескриптор очереди сообщений ¦

¦ (2) адрес структуры сообщения ¦

¦ (4) флаги ¦

¦ выходная информация: количество посланных байт ¦

¦ { ¦

¦ проверить правильность указания дескриптора и наличие ¦

¦ соответствующих прав доступа; ¦

¦ выполнить пока (для хранения сообщения не будет выделено¦

¦ место) ¦

¦ { ¦

¦ если (флаги не разрешают ждать) ¦

¦ вернуться; ¦

¦ приостановиться (до тех пор, пока место не освобо- ¦

¦ } ¦

¦ получить заголовок сообщения; ¦

¦ считать текст сообщения из пространства задачи в прост- ¦

¦ настроить структуры данных: выстроить очередь заголовков¦

¦ сообщений, установить в заголовке указатель на текст ¦

¦ сообщения, заполнить поля, содержащие счетчики, время ¦

¦ последнего выполнения операций и идентификатор процес- ¦

¦ са; ¦

¦ вывести из состояния приостанова все процессы, ожидающие¦

¦ разрешения считать сообщение из очереди; ¦

¦ } ¦

L------------------------------------------------------------

Рисунок 11.4. Алгоритм посылки сообщения

ния, устанавливается указатель на текст сообщения и производится корректировка содержимого различных полей заголовка очереди, содержащих статистическую информацию (количество сообщений в очереди и их суммарный объем в байтах, время последнего выполнения операций и идентификатор процесса, пославшего сообщение). Затем ядро выводит из состояния приостанова все процессы, ожидающие пополнения очереди сообщений. Если размер очереди в байтах превышает границу допустимости, процесс приостанавливается до тех пор, пока другие сообщения не уйдут из очереди. Однако, если процессу было дано указание не ждать (флаг IPC_NOWAIT), он немедленно возвращает управление с уведомлением об ошибке. На Рисунке 11.5 показана очередь сообщений, состоящая из заголовков сообщений, организованных в связные списки, с указателями на область текста.

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

count = msgrcv(id,msg,maxcount,type,flag);

где id - дескриптор сообщения, msg - адрес пользовательской структуры, которая будет содержать полученное сообщение, maxcount - размер структуры msg, type - тип считываемого сообщения, flag - действие, предпринимаемое ядром в том случае, если в очереди со

Заголовки Область

очередей текста

-------¬ Заголовки сообщений -->-------¬

¦ ¦ -------¬ -------¬ -------¬ ¦ ¦ ¦

¦ --+---->¦ +--->¦ +--->¦ ¦ ¦ ¦ ¦

¦ ¦ L---+--- L---+--- L---+--- ¦ ¦ ¦

+------+ ¦ ¦ L----- ¦ ¦

¦ ¦ L-----------¦------------------>+------+

¦ ¦ ¦ ¦ ¦

¦ ¦ ¦ ¦ ¦

+------+ ¦ ¦ ¦

¦ ¦ -------¬ ¦ ¦ ¦

¦ --+---->¦ ¦ ¦ ¦ ¦

¦ ¦ L---+--- ¦ ¦ ¦

+------+ ¦ ¦ ¦ ¦

¦ • ¦ ¦ ¦ +------+

¦ • ¦ L-----------¦------------------>+------+

¦ • ¦ ¦ ¦ ¦

¦ • ¦ ¦ ¦ ¦

¦ • ¦ L------------------>+------+

¦ • ¦ ¦ ¦

¦ • ¦ +------+

¦ • ¦ ¦ • ¦

¦ • ¦ ¦ • ¦

¦ • ¦ ¦ • ¦

L------- L------

Рисунок 11.5. Структуры данных, используемые в организации сообщений

общений нет. В переменной count пользователю возвращается число прочитанных байт сообщения.

-------------------------------------------------------------¬

¦ #include <sys/types.h> ¦

¦ #include <sys/ipc.h> ¦

¦ #include <sys/msg.h> ¦

¦ ¦

¦ #define MSGKEY 75 ¦

¦ ¦

¦ struct msgform { ¦

¦ long mtype; ¦

¦ char mtext[256]; ¦

¦ }; ¦

¦ ¦

¦ main() ¦

¦ { ¦

¦ struct msgform msg; ¦

¦ int msgid,pid,*pint; ¦

¦ ¦

¦ msgid = msgget(MSGKEY,0777); ¦

¦ ¦

¦ pid = getpid(); ¦

¦ pint = (int *) msg.mtext; ¦

¦ *pint = pid; /* копирование идентификатора ¦

¦ * процесса в область текста ¦

¦ * сообщения */ ¦

¦ msg.mtype = 1; ¦

¦ ¦

¦ msgsnd(msgid,&msg,sizeof(int),0); ¦

¦ msgrcv(msgid,&msg,256,pid,0); /* идентификатор ¦

¦ * процесса используется в ¦

¦ * качестве типа сообщения */ ¦

¦ printf("клиент: получил от процесса с pid %d\n", ¦

¦ *pint); ¦

¦ } ¦

L------------------------------------------------------------

Рисунок 11.6. Пользовательский процесс

Процесс может получать сообщения определенного типа, если присвоит параметру type соответствующее значение. Если это положительное целое число, функция возвращает первое значение данного типа, если отрицательное, ядро определяет минимальное значение типа сообщений в очереди, и если оно не превышает абсолютное значение параметра type, возвращает процессу первое сообщение этого типа. Например, если очередь состоит из трех сообщений, имеющих тип 3, 1 и 2, соответственно, а пользователь запрашивает сообщение с типом -2, ядро возвращает ему сообщение типа 1. Во всех случаях, если условиям запроса не удовлетворяет ни одно из сообщений в очереди, ядро переводит процесс в состояние приостанова, разумеется если только в параметре flag не установлен бит IPC_NOWAIT (иначе процесс немедленно выходит из функции).

Рассмотрим программы, представленные на Рисунках 11.6 и 11.8. Программа на Рисунке 11.8 осуществляет общее обслуживание запросов пользовательских процессов (клиентов). Запросы, например, могут касаться информации, хранящейся в базе данных; обслуживающий процесс (сервер) выступает необходимым посредником при обращении к базе данных, такой порядок облегчает поддержание целостности данных и организацию их защиты от несанкционированного доступа. Обслуживающий процесс создает сообщение путем установки флага IPC _CREAT при

-------------------------------------------------------------¬

¦ алгоритм msgrcv /* получение сообщения */ ¦

¦ входная информация: (1) дескриптор сообщения ¦

¦ сообщение ¦

¦ (3) размер массива ¦

¦ (4) тип сообщения в запросе ¦

¦ выходная информация: количество байт в полученном сообщении¦

¦ { ¦

¦ проверить права доступа; ¦

¦ loop: ¦

¦ проверить правильность дескриптора сообщения; ¦

¦ /* найти сообщение, нужное пользователю */ ¦

¦ если (тип сообщения в запросе == 0) ¦

¦ рассмотреть первое сообщение в очереди; ¦

¦ в противном случае если (тип сообщения в запросе > 0) ¦

¦ рассмотреть первое сообщение в очереди, имеющее ¦

¦ данный тип; ¦

¦ в противном случае /* тип сообщения в запросе < 0 */¦

¦ рассмотреть первое из сообщений в очереди с наи- ¦

¦ меньшим значением типа при условии, что его тип ¦

¦ не превышает абсолютное значение типа, указанно-¦

¦ если (сообщение найдено) ¦

¦ { ¦

¦ переустановить размер сообщения или вернуть ошиб-¦

¦ ку, если размер, указанный пользователем слишком¦

¦ мал; ¦

¦ скопировать тип сообщения и его текст из прост- ¦

¦ ранства ядра в пространство задачи; ¦

¦ разорвать связь сообщения с очередью; ¦

¦ вернуть управление; ¦

¦ } ¦

¦ /* сообщений нет */ ¦

¦ если (флаги не разрешают приостанавливать работу) ¦

¦ вернуть управление с ошибкой; ¦

¦ приостановиться (пока сообщение не появится в очере- ¦

¦ ди); ¦

¦ } ¦

L-------------------------------------------------------------

Рисунок 11.7. Алгоритм получения сообщения

-------------------------------------------------------------¬

¦ #include <sys/types.h> ¦

¦ #include <sys/ipc.h> ¦

¦ #include <sys/msg.h> ¦

¦ ¦

¦ #define MSGKEY 75 ¦

¦ struct msgform ¦

¦ { ¦

¦ long mtype; ¦

¦ char mtext[256]; ¦

¦ }msg; ¦

¦ int msgid; ¦

¦ ¦

¦ main() ¦

¦ { ¦

¦ int i,pid,*pint; ¦

¦ extern cleanup(); ¦

¦ ¦

¦ for (i = 0; i < 20; i++) ¦

¦ signal(i,cleanup); ¦

¦ msgid = msgget(MSGKEY,0777¦IPC_CREAT); ¦

¦ ¦

¦ for (;;) ¦

¦ { ¦

¦ msgrcv(msgid,&msg,256,1,0); ¦

¦ pint = (int *) msg.mtext; ¦

¦ pid = *pint; ¦

¦ pid); ¦

¦ msg.mtype = pid; ¦

¦ *pint = getpid(); ¦

¦ msgsnd(msgid,&msg,sizeof(int),0); ¦

¦ } ¦

¦ } ¦

¦ ¦

¦ cleanup() ¦

¦ { ¦

¦ msgctl(msgid,IPC_RMID,0); ¦

¦ exit(); ¦

¦ } ¦

L------------------------------------------------------------

Рисунок 11.8. Обслуживающий процесс (сервер)

Сообщения имеют форму "тип - текст", где текст представляет собой поток байтов. Указание типа дает процессам возможность выбирать сообщения только определенного рода, что в файловой системе не так легко сделать. Таким образом, процессы могут выбирать из очереди сообщения определенного типа в порядке их поступления, причем эта очередность гарантируется ядром. Несмотря на то, что обмен сообщениями может быть реализован на пользовательском уровне средствами файловой системы, представленный вашему вниманию механизм обеспечивает более эффективную организацию передачи данных между процессами.

С помощью системной функции msgctl процесс может запросить информацию о статусе дескриптора сообщения, установить этот статус или удалить дескриптор сообщения из системы. Синтаксис вызова функции:

msgctl(id,cmd,mstatbuf)

где id - дескриптор сообщения, cmd - тип команды, mstatbuf - адрес пользовательской структуры, в которой будут храниться управляющие параметры или результаты обработки запроса. Более подробно об аргументах функции пойдет речь в Приложении.

Вернемся к примеру, представленному на Рисунке 11.8. Обслуживающий процесс принимает сигналы и с помощью функции cleanup удаляет очередь сообщений из системы. Если же им не было поймано ни одного сигнала или был получен сигнал SIGKILL, очередь сообщений остается в системе, даже если на нее не ссылается ни один из процессов. Дальнейшие попытки исключительно создания новой очереди сообщений с данным ключом (идентификатором) не будут иметь успех до тех пор, пока старая очередь не будет удалена из системы.

Процессы могут взаимодействовать друг с другом непосредственно путем разделения (совместного использования) участков виртуального адресного пространства и обмена данными через разделяемую память. Системные функции для работы с разделяемой памятью имеют много сходного с системными функциями для работы с сообщениями. Функция shmget создает новую область разделяемой памяти или возвращает адрес уже существующей области, функция shmat логически присоединяет область к виртуальному адресному пространству процесса, функция shmdt отсоединяет ее, а функция shmctl имеет дело с различными параметрами, связанными с разделяемой памятью. Процессы ведут чтение и запись данных в области разделяемой памяти, используя для этого те же самые машинные команды, что и при работе с обычной памятью. После присоединения к виртуальному адресному пространству процесса область разделяемой памяти становится доступна так же, как любой участок виртуальной памяти; для доступа к находящимся в ней данным не нужны обращения к каким-то дополнительным системным функциям.

Синтаксис вызова системной функции shmget:

shmid = shmget(key,size,flag);

Таблица раз- Таблица процессов -

деляемой па- Таблица областей частная таблица об-

мяти ластей процесса

-----------¬ ---------------¬ ----------¬

¦ ----+----¬ ¦ ¦ -----+---- ¦

+----------+ -¦->+--------------+<----- +---------+

¦ ----+----¦ ¦ ¦ ----+---- ¦

+----------+ ¦ +--------------+<----¬¦ +---------+

¦ ----+--¬ ¦ ¦ ¦ L¦---+---- ¦

+----------+ ¦ ¦ +--------------+ ¦ +---------+

¦ • ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦

¦ • ¦ ¦ L->+--------------+ ¦ +---------+

¦ • ¦ ¦ ¦ ¦ ¦ ¦ ¦

¦ • ¦ L--->+--------------+<------ +---------+

¦ • ¦ ¦ ¦ (после ¦ ¦

¦ • ¦ +--------------+ shmat) +---------+

¦ • ¦ ¦ • ¦ ¦ ¦

¦ • ¦ ¦ • ¦ +---------+

¦ • ¦ L--------------- ¦ • ¦

¦ • ¦ ¦ • ¦

L----------- L---------

Рисунок 11.9. Структуры данных, используемые при разделении памяти

Процесс присоединяет область разделяемой памяти к своему виртуальному адресному пространству с помощью системной функции shmat:

virtaddr = shmat(id,addr,flags);

Значение id, возвращаемое функцией shmget, идентифицирует область разделяемой памяти, addr является виртуальным адресом, по которому пользователь хочет подключить область, а с помощью флагов (flags) можно указать, предназначена ли область только для чтения и нужно ли ядру округлять значение указанного пользователем адреса. Возвращаемое функцией значение, virtaddr, представляет собой виртуальный адрес, по которому ядро произвело подключение области и который не всегда совпадает с адресом, указанным пользователем.

В начале выполнения системной функции shmat ядро проверяет наличие у процесса необходимых прав доступа к области (Рисунок 11.10). Оно исследует указанный пользователем адрес; если он равен 0, ядро выбирает виртуальный адрес по своему усмотрению.

Область разделяемой памяти не должна пересекаться в виртуальном адресном пространстве процесса с другими областями; следовательно, ее выбор должен производиться разумно и осторожно. Так, например, процесс может увеличить размер принадлежащей ему области данных с помощью системной функции brk, и новая область данных будет содержать адреса, смежные с прежней областью; поэтому, ядру не следует присоединять область разделяемой памяти слишком близко к области данных процесса. Так же не следует размещать область разделяемой памяти вблизи от вершины стека, чтобы стек при своем последующем увеличении не залезал за ее пределы. Если, например, стек растет в направлении увеличения адресов, лучше всего разместить область разделяемой памяти непосредственно перед началом области стека.

Ядро проверяет возможность размещения области разделяемой памяти в ад

-------------------------------------------------------------¬

¦ алгоритм shmat /* подключить разделяемую память */ ¦

¦ входная информация: (1) дескриптор области разделяемой ¦

¦ (2) виртуальный адрес для подключения ¦

¦ области ¦

¦ (3) флаги ¦

¦ выходная информация: виртуальный адрес, по которому область¦

¦ подключена фактически ¦

¦ { ¦

¦ проверить правильность указания дескриптора, права до- ¦

¦ если (пользователь указал виртуальный адрес) ¦

¦ { ¦

¦ округлить виртуальный адрес в соответствии с фла- ¦

¦ проверить существование полученного адреса, размер¦

¦ области; ¦

¦ } ¦

¦ в противном случае /* пользователь хочет, чтобы ядро ¦

¦ * само нашло подходящий адрес */ ¦

¦ ядро выбирает адрес: в случае неудачи выдается ¦

¦ ошибка; ¦

¦ присоединить область к адресному пространству процесса ¦

¦ (алгоритм attachreg); ¦

¦ если (область присоединяется впервые) ¦

¦ выделить таблицы страниц и отвести память под нее ¦

¦ вернуть (виртуальный адрес фактического присоединения ¦

¦ области); ¦

¦ } ¦

L------------------------------------------------------------

Рисунок 11.10. Алгоритм присоединения разделяемой памяти

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

Отсоединение области разделяемой памяти от виртуального адресного пространства процесса выполняет функция

shmdt(addr)

где addr - виртуальный адрес, возвращенный функцией shmat. Несмотря на то, что более логичной представляется передача идентификатора, процесс использует виртуальный адрес разделяемой памяти, поскольку одна и та же область разделяемой памяти может быть подключена к адресному пространству процесса несколько раз, к тому же ее идентификатор может быть удален из системы. Ядро производит поиск области по указанному адресу и отсоединяет ее от адресного пространства процесса, используя алгоритм detachreg (раздел 6.5.7). Поскольку в таблицах областей отсутствуют обратные указатели на таблицу разделяемой памяти, ядру приходится просматривать таблицу разделяемой памяти в поисках записи, указывающей на данную область, и записывать в соответствующее поле время последнего отключения области.

Рассмотрим программу, представленную на Рисунке 11.11. В ней описывается процесс, создающий область разделяемой памяти размером 128 Кбайт и дважды присоединяющий ее к своему адресному пространству по разным виртуальным адресам. В "первую" область он записывает данные, а читает их из "второй" области. На Рисунке 11.12 показан другой процесс, присоединяющий ту же область (он получает только 64 Кбайта, таким образом, каждый процесс может использовать разный объем области разделяемой памяти); он ждет момента, когда первый процесс запишет в первое принадлежащее области слово любое отличное от нуля значение, и затем принимается считывать данные из области. Первый процесс делает "паузу" (pause), предоставляя второму процессу возможность выполнения; когда первый процесс принимает сигнал, он удаляет область разделяемой памяти из системы.

Процесс запрашивает информацию о состоянии области разделяемой памяти и производит установку параметров для нее с помощью системной функции shmctl:

shmctl(id,cmd,shmstatbuf);

Системные функции работы с семафорами обеспечивают синхронизацию выполнения параллельных процессов, производя набор действий единственно над группой семафоров (средствами низкого уровня). До использования семафоров, если процессу нужно было заблокировать некий ресурс, он прибегал к созданию с помощью системной функции creat специального блокирующего файла. Если файл уже существовал, функция creat завершалась неудачно, и процесс делал вывод о том, что ресурс уже заблокирован другим процессом. Главные недостатки такого подхода заключались в том, что процесс не знал, в какой момент ему следует предпринять следующую попытку, а также в том, что блокирующие файлы случайно оставались в системе в случае ее аварийного завершения или перезагрузки.

Семафор в версии V системы UNIX состоит из следующих элементов:

Для создания набора семафоров и получения доступа к ним используется системная функция semget, для выполнения различных управляющих операций над набором - функция semctl, для работы со значениями семафоров - функция semop.

-------------------------------------------------------------¬

¦ #include <sys/types.h> ¦

¦ #include <sys/ipc.h> ¦

¦ #include <sys/shm.h> ¦

¦ #define SHMKEY 75 ¦

¦ #define K 1024 ¦

¦ int shmid; ¦

¦ ¦

¦ main() ¦

¦ { ¦

¦ int i, *pint; ¦

¦ char *addr1, *addr2; ¦

¦ extern char *shmat(); ¦

¦ extern cleanup(); ¦

¦ ¦

¦ for (i = 0; i < 20; i++) ¦

¦ signal(i,cleanup); ¦

¦ shmid = shmget(SHMKEY,128*K,0777¦IPC_CREAT); ¦

¦ addr1 = shmat(shmid,0,0); ¦

¦ addr2 = shmat(shmid,0,0); ¦

¦ printf("addr1 Ox%x addr2 Ox%x\n",addr1,addr2); ¦

¦ pint = (int *) addr1; ¦

¦ ¦

¦ for (i = 0; i < 256, i++) ¦

¦ *pint++ = i; ¦

¦ pint = (int *) addr1; ¦

¦ *pint = 256; ¦

¦ ¦

¦ pint = (int *) addr2; ¦

¦ for (i = 0; i < 256, i++) ¦

¦ printf("index %d\tvalue %d\n",i,*pint++); ¦

¦ ¦

¦ pause(); ¦

¦ } ¦

¦ ¦

¦ cleanup() ¦

¦ { ¦

¦ shmctl(shmid,IPC_RMID,0); ¦

¦ exit(); ¦

¦ } ¦

L------------------------------------------------------------

Рисунок 11.11. Присоединение процессом одной и той же области

разделяемой памяти дважды

345_

------------------------------------------------------¬

¦ #include <sys/types.h> ¦

¦ #include <sys/ipc.h> ¦

¦ #include <sys/shm.h> ¦

¦ ¦

¦ #define SHMKEY 75 ¦

¦ #define K 1024 ¦

¦ int shmid; ¦

¦ ¦

¦ main() ¦

¦ { ¦

¦ int i, *pint; ¦

¦ char *addr; ¦

¦ extern char *shmat(); ¦

¦ ¦

¦ shmid = shmget(SHMKEY,64*K,0777); ¦

¦ ¦

¦ addr = shmat(shmid,0,0); ¦

¦ pint = (int *) addr; ¦

¦ ¦

¦ while (*pint == 0) ¦

¦ ; ¦

¦ for (i = 0; i < 256, i++) ¦

¦ printf("%d\n",*pint++); ¦

¦ } ¦

L-----------------------------------------------------

Рисунок 11.12. Разделение памяти между процессами

Таблица семафоров Массивы семафоров

--------¬

¦ ¦ ----T---T---T---T---T---T---¬

¦ +------->¦ 0 ¦ 1 ¦ 2 ¦ 3 ¦ 4 ¦ 5 ¦ 6 ¦

¦ ¦ L---+---+---+---+---+---+----

+-------+

¦ ¦ ----T---T---¬

¦ +------->¦ 0 ¦ 1 ¦ 2 ¦

¦ ¦ L---+---+----

+-------+

¦ ¦ ----¬

¦ +------->¦ 0 ¦

¦ ¦ L----

+-------+

¦ ¦ ----T---T---¬

¦ +------->¦ 0 ¦ 1 ¦ 2 ¦

¦ ¦ L---+---+----

+-------+

¦ • ¦

¦ • ¦

¦ • ¦

¦ • ¦

¦ • ¦

L-------

Рисунок 11.13. Структуры данных, используемые в работе над семафорами

Синтаксис вызова системной функции semget:

id = semget(key,count,flag);

Синтаксис вызова системной функции semop:

oldval = semop(id,oplist,count);

где id - дескриптор, возвращаемый функцией semget, oplist - указатель на список операций, count - размер списка. Возвращаемое функцией значение oldval является прежним значением семафора, над

-------------------------------------------------------------¬

¦ #include <sys/types.h> ¦

¦ #include <sys/ipc.h> ¦

¦ #include <sys/sem.h> ¦

¦ ¦

¦ #define SEMKEY 75 ¦

¦ int semid; ¦

¦ unsigned int count; ¦

¦ /* определение структуры sembuf в файле sys/sem.h ¦

¦ * struct sembuf { ¦

¦ * unsigned shortsem_num; ¦

¦ * short sem_op; ¦

¦ * short sem_flg; ¦

¦ }; */ ¦

¦ struct sembuf psembuf,vsembuf; /* операции типа P и V */¦

¦ ¦

¦ main(argc,argv) ¦

¦ int argc; ¦

¦ char *argv[]; ¦

¦ { ¦

¦ int i,first,second; ¦

¦ short initarray[2],outarray[2]; ¦

¦ extern cleanup(); ¦

¦ ¦

¦ if (argc == 1) ¦

¦ { ¦

¦ for (i = 0; i < 20; i++) ¦

¦ signal(i,cleanup); ¦

¦ semid = semget(SEMKEY,2,0777¦IPC_CREAT); ¦

¦ initarray[0] = initarray[1] = 1; ¦

¦ semctl(semid,2,SETALL,initarray); ¦

¦ semctl(semid,2,GETALL,outarray); ¦

¦ printf("начальные значения семафоров %d %d\n", ¦

¦ outarray[0],outarray[1]); ¦

¦ pause(); /* приостанов до получения сигнала */ ¦

¦ } ¦

¦ ¦

¦ /* продолжение на следующей странице */ ¦

L------------------------------------------------------------

Рисунок 11.14. Операции установки и снятия блокировки

которым производилась операция. Каждый элемент списка операций имеет следующий формат:

-------------------------------------------------------------¬

¦ else if (argv[1][0] == 'a') ¦

¦ { ¦

¦ first = 0; ¦

¦ second = 1; ¦

¦ } ¦

¦ else ¦

¦ { ¦

¦ first = 1; ¦

¦ second = 0; ¦

¦ } ¦

¦ ¦

¦ semid = semget(SEMKEY,2,0777); ¦

¦ psembuf.sem_op = -1; ¦

¦ psembuf.sem_flg = SEM_UNDO; ¦

¦ vsembuf.sem_op = 1; ¦

¦ vsembuf.sem_flg = SEM_UNDO; ¦

¦ ¦

¦ for (count = 0; ; count++) ¦

¦ { ¦

¦ psembuf.sem_num = first; ¦

¦ semop(semid,&psembuf,1); ¦

¦ psembuf.sem_num = second; ¦

¦ semop(semid,&psembuf,1); ¦

¦ printf("процесс %d счетчик %d\n",getpid(),count); ¦

¦ vsembuf.sem_num = second; ¦

¦ semop(semid,&vsembuf,1); ¦

¦ vsembuf.sem_num = first; ¦

¦ semop(semid,&vsembuf,1); ¦

¦ } ¦

¦ } ¦

¦ ¦

¦ cleanup() ¦

¦ { ¦

¦ semctl(semid,2,IPC_RMID,0); ¦

¦ exit(); ¦

¦ } ¦

L------------------------------------------------------------

Рисунок 11.14. Операции установки и снятия блокировки (продолжение)

Ядро считывает список операций oplist из адресного пространства задачи и проверяет корректность номеров семафоров, а также наличие у процесса необходимых разрешений на чтение и корректировку семафоров (Рисунок 11.15). Если таких разрешений не имеется, системная функция завершается неудачно. Если ядру приходится приостанавливать свою работу при обращении к списку операций, оно возвращает семафорам их прежние значения и находится в состоянии приостанова до наступления ожидаемого события, после чего системная функция запускается вновь. Поскольку ядро хранит коды операций над семафорами в глобальном списке, оно вновь считывает этот список из пространства

-------------------------------------------------------------¬

¦ алгоритм semop /* операции над семафором */ ¦

¦ входная информация: (1) дескриптор семафора ¦

¦ (2) список операций над семафором ¦

¦ (3) количество элементов в списке ¦

¦ выходная информация: исходное значение семафора ¦

¦ { ¦

¦ проверить корректность дескриптора семафора; ¦

¦ start: считать список операций над семафором из простран- ¦

¦ ства задачи в пространство ядра; ¦

¦ проверить наличие разрешений на выполнение всех опера- ¦

¦ ций; ¦

¦ ¦

¦ для (каждой операции в списке) ¦

¦ { ¦

¦ если (код операции имеет положительное значение) ¦

¦ { ¦

¦ прибавить код операции к значению семафора; ¦

¦ скорректировать структуру восстановления ¦

¦ для данного процесса; ¦

¦ вывести из состояния приостанова все процессы, ¦

¦ ожидающие увеличения значения семафора; ¦

¦ } ¦

¦ в противном случае если (код операции имеет отрица-¦

¦ тельное значение) ¦

¦ { ¦

¦ { ¦

¦ прибавить код операции к значению семафо- ¦

¦ ра; ¦

¦ скорректировать структуру восстанов- ¦

¦ ления для данного процесса; ¦

¦ если (значение семафора равно 0) ¦

¦ * це */ ¦

L------------------------------------------------------------

Рисунок 11.15. Алгоритм выполнения операций над семафором

задачи, когда перезапускает системную функцию. Таким образом, операции выполняются комплексно - или все за один сеанс или ни одной.

-------------------------------------------------------------¬

¦ процессы, ожидающие обнуления значе-¦

¦ ния семафора; ¦

¦ продолжить; ¦

¦ } ¦

¦ выполнить все произведенные над семафором в ¦

¦ данном сеансе операции в обратной последова- ¦

¦ тельности (восстановить старое значение сема- ¦

¦ если (флаги не велят приостанавливаться) ¦

¦ вернуться с ошибкой; ¦

¦ приостановиться (до тех пор, пока значение се- ¦

¦ мафора не увеличится); ¦

¦ перейти на start; /* повторить цикл с самого ¦

¦ * начала * / ¦

¦ } ¦

¦ в противном случае /* код операции равен нулю */¦

¦ { ¦

¦ если (значение семафора отлично от нуля) ¦

¦ { ¦

¦ выполнить все произведенные над семафором ¦

¦ в данном сеансе операции в обратной по- ¦

¦ следовательности (восстановить старое ¦

¦ значение семафора); ¦

¦ если (флаги не велят приостанавливаться) ¦

¦ вернуться с ошибкой; ¦

¦ приостановиться (до тех пор, пока значение¦

¦ семафора не станет нулевым); ¦

¦ перейти на start; /* повторить цикл */ ¦

¦ } ¦

¦ } ¦

¦ } /* конец цикла */ ¦

¦ скорректировать значения полей, в которых хранится вре-¦

¦ мя последнего выполнения операций и идентификаторы ¦

¦ процессов; ¦

¦ вернуть исходное значение семафора, существовавшее в ¦

¦ момент вызова функции semop; ¦

¦ } ¦

L------------------------------------------------------------

Рисунок 11.15. Алгоритм выполнения операций над семафором (продолжение)

Перейдем к программе, представленной на Рисунке 11.14, и предположим, что пользователь исполняет ее (под именем a.out) три раза в следующем порядке:

a.out &

a.out a &

a.out b &

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

struct sembuf psembuf[2];

psembuf[0].sem_num = 0;

psembuf[1].sem_num = 1;

psembuf[0].sem_op = -1;

psembuf[1].sem_op = -1;

semop(semid,psembuf,2);

Установка флага IPC_NOWAIT в функции semop имеет следующий смысл: если ядро попадает в такую ситуацию, когда процесс должен приостановить свое выполнение в ожидании увеличения значения семафора выше определенного уровня или, наоборот, снижения этого значения до 0, и если при этом флаг IPC_NOWAIT установлен, ядро выходит из функции с извещением об ошибке. Таким образом, если не приостанавливать процесс в случае невозможности выполнения отдельной операции, можно реализовать условный тип семафора.

Ядро выделяет структуры восстановления динамически, во время первого выполнения системной функции semop с установленным флагом SEM_UNDO. При последующих обращениях к функции с тем же флагом ядро просматривает структуры восстановления для процесса в поисках структуры с тем же самым идентификато

Заголовки частных структур

восстановления Структуры восстановления

-------¬

¦ • ¦

¦ • ¦

¦ • ¦

¦ • ¦ -----------¬ -----------¬ -----------¬

+------+ ¦Дескриптор¦ ¦Дескриптор¦ ¦Дескриптор¦

¦ +-->¦ Номер +-->¦ Номер +-->¦ Номер ¦

+------+ ¦ Значение ¦ ¦ Значение ¦ ¦ Значение ¦

¦ ¦ L----------- L----------- L-----------

¦ ¦ -----------¬

+------+ ¦Дескриптор¦

¦ +-->¦ Номер ¦

¦ • ¦ L-----------

¦ • ¦

¦ • ¦

¦ • ¦

L------

Рисунок 11.16. Структуры восстановления семафоров

----------------TT-------¬ ----------------TT-------T-------¬

¦ идентификато𠦦 ¦ ¦ идентификато𠦦 ¦ ¦

¦ семафора ¦¦ semid ¦ ¦ семафора ¦¦ semid ¦ semid ¦

+---------------++-------+ +---------------++-------+-------+

¦ номер семафорদ 0 ¦ ¦ номер семафорদ 0 ¦ 1 ¦

+---------------++-------+ +---------------++-------+-------+

¦ установочное ¦¦ ¦ ¦ установочное ¦¦ ¦ ¦

L---------------++-------- L---------------++-------+--------

(а) После первой операции (б) После второй операции

----------------TT-------¬

¦ идентификато𠦦 ¦

¦ семафора ¦¦ semid ¦

+---------------++-------+

¦ номер семафорদ 0 ¦ пусто

+---------------++-------+

¦ установочное ¦¦ ¦

¦ значение ¦¦ 1 ¦

L---------------++--------

(в) После третьей операции (г) После четвертой операции

Рисунок 11.17. Последовательность состояний списка структур восстановления

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

Ядро создает структуру восстановления всякий раз, когда процесс уменьшает значение семафора, а удаляет ее, когда процесс увеличивает значение семафора, поскольку установочное значение структуры равно 0. На Рисунке 11.17 показана последовательность состояний списка структур при выполнении программы с параметром 'a'. После первой операции процесс имеет одну структуру, состоящую из идентификатора semid, номера семафора, равного 0, и установочного значения, равного 1, а после второй операции появляется вторая структура с номером семафора, равным 1, и установочным значением, равным 1. Если процесс неожиданно завершается, ядро проходит по всем структурам и прибавляет к каждому семафору по единице, восстанавливая их значения в 0. В частном случае ядро уменьшает установочное значение для семафора 1 на третьей операции, в соответствии с увеличением значения самого семафора, и удаляет всю структуру целиком, поскольку установочное значение становится нулевым. После четвертой операции у процесса больше нет структур восстановления, поскольку все установочные значения стали нулевыми.

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

Синтаксис вызова системной функции semctl:

semctl(id,number,cmd,arg);

Параметр arg объявлен как объединение типов данных:

union semunion {

int val;

struct semid_ds *semstat; /* описание типов см. в При-

unsigned short *array;

} arg;

Вместо традиционных, получивших широкое распространение файлов механизмы взаимодействия процессов используют новое пространство имен, состоящее из ключей (keys). Расширить семантику ключей на всю сеть довольно трудно, поскольку на разных машинах ключи могут описывать различные объекты. Короче говоря, ключи в основном предназначены для использования в одномашинных системах. Имена файлов в большей степени подходят для распределенных систем (см. главу 13). Использование ключей вместо имен файлов также свидетельствует о том, что средства взаимодействия процессов являются "вещью в себе", полезной в специальных приложениях, но не имеющей тех возможностей, которыми обладают, например, каналы и файлы. Большая часть функциональных возможностей, предоставляемых данными средствами, может быть реализована с помощью других системных средств, поэтому включать их в состав ядра вряд ли следовало бы. Тем не менее, их использование в составе пакетов прикладных программ тесного взаимодействия дает лучшие результаты по сравнению со стандартными файловыми средствами (см. Упражнения).

Поскольку в системе UNIX новые процессы создаются с помощью системной функции fork, к тому моменту, когда клиент попытается выполнить подключение, обслуживающий процесс уже должен существовать. Если бы в момент создания нового процесса удаленное ядро получало запрос на подключение (по каналам межмашинной связи), возникла бы несогласованность с архитектурой системы. Чтобы избежать этого, некий процесс, обычно init, порождает обслуживающий процесс, который ведет чтение из канала связи, пока не получает запрос на обслуживание, после чего в соответствии с некоторым протоколом выполняет установку соединения. Выбор сетевых средств и протоколов обычно выполняют программы клиента и сервера, основываясь на информации, хранящейся в прикладных базах данных; с другой стороны, выбранные пользователем средства могут быть закодированы в самих программах.

Чтобы разработать сетевые интерфейсы для системы UNIX, были предприняты значительные усилия. Реализация потоков в последних редакциях версии V располагает элегантным механизмом поддержки сетевого взаимодействия, обеспечивающим гибкое сочетание отдельных модулей протоколов и их согласованное использование на уровне задач. Следующий раздел посвящен краткому описанию метода решения данных проблем в системе BSD, основанного на использовании гнезд.

Процесс-клиент Процесс-сервер

¦ ¦

L--¬ ----

--------------------------+--¬ ---+--------------------------¬

¦ Уровень гнезд ¦ ¦ Уровень гнезд ¦

+-------------------------+--+ +--+--------------------------+

¦ TCP ¦ ¦ TCP ¦

¦ Уровень протоколов ¦ ¦ ¦ ¦ Уровень протоколов ¦

¦ IP ¦ ¦ IP ¦

+-------------------------+--+ +--+--------------------------+

¦ Драйвер¦ ¦ Драйвер ¦

¦ Уровень устройств Ethernet¦ ¦Ethernet Уровень устройств ¦

L-------------------------+--- L--+---------------------------

L---¬ -----

¦ ¦

С е т ь

Рисунок 11.18. Модель с использованием гнезд

Существует несколько системных функций работы с гнездами. Функция socket устанавливает оконечную точку линии связи.

sd = socket(format,type,protocol);

Format обозначает домен ("UNIX system" или "Internet"), type - тип связи через гнездо (виртуальный канал или дейтаграмма), а protocol - тип протокола, управляющего взаимодействием. Дескриптор гнезда sd, возвращаемый функцией socket, используется другими системными функциями. Закрытие гнезд выполняет функция close.

Функция bind связывает дескриптор гнезда с именем:

bind(sd,address,length); где sd - дескриптор гнезда, address - адрес структуры, определяющей идентификатор, характерный для данной комбинации домена и протокола (в функции socket). Length - длина структуры address; без этого параметра ядро не знало бы, какова длина структуры, поскольку для разных доменов и протоколов она может быть различной. Например, для домена "UNIX system" структура содержит имя файла. Процессы-серверы связывают гнезда с именами и объявляют о состоявшемся присвоении имен процессам-клиентам.

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

connect(sd,address,length); Семантический смысл параметров функции остается прежним (см. функцию bind), но address указывает уже на выходное гнездо, образующее противоположный конец линии связи. Оба гнезда должны использовать одни и те же домен и протокол связи, и тогда ядро удостоверит правильность установки линии связи. Если тип гнезда - дейтаграмма, сообщаемый функцией connect ядру адрес будет использоваться в последующих обращениях к функции send через данное гнездо; в момент вызова никаких соединений не производится.

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

listen(sd,qlength)

где sd - дескриптор гнезда, а qlength - максимально-допустимое число запросов, ожидающих обработки.

---------------------¬ --------------------------¬

¦ Процесс-клиент ¦ ¦ Процесс-сервер ¦

¦ ¦ ¦ ¦ ¦ • ¦

¦ ¦ ¦ ¦ ------ •••••• ¦

¦ ¦ ¦ ¦ ¦ • ¦

¦ ¦ ¦ ¦listen addr accept addr¦

L---------+----------- L-----+------------•-------

¦ ¦ •

L---------------------------•••••••••••••

Рисунок 11.19. Прием вызова сервером

Системная функция accept принимает запросы на подключение, поступающие на вход процесса-сервера:

nsd = accept(sd,address,addrlen);

где sd - дескриптор гнезда, address - указатель на пользовательский массив, в котором ядро возвращает адрес подключаемого клиента, addrlen - размер пользовательского массива. По завершении выполнения функции ядро записывает в переменную addrlen размер пространства, фактически занятого массивом. Функция возвращает новый дескриптор гнезда (nsd), отличный от дескриптора sd. Процесс-сервер может продолжать слежение за состоянием объявленного гнезда, поддерживая связь с клиентом по отдельному каналу (Рисунок 11.19).

Функции send и recv выполняют передачу данных через подключенное гнездо. Синтаксис вызова функции send:

count = send(sd,msg,length,flags);

где sd - дескриптор гнезда, msg - указатель на посылаемые данные, length размер данных, count - количество фактически переданных байт. Параметр flags может содержать значение SOF_OOB (послать данные out-of-band - "через таможню"), если посылаемые данные не учитываются в общем информационном обмене между взаимодействующими процессами. Программа удаленной регистрации, например, может послать out-of-band сообщение, имитирующее нажатие на клавиатуре терминала клавиши "delete". Синтаксис вызова системной функции recv:

count = recv(sd,buf,length,flags);

Функция shutdown закрывает гнездовую связь:

shutdown(sd,mode)

где mode указывает, какой из сторон (посылающей, принимающей или обеим вместе) отныне запрещено участие в процессе передачи данных. Функция сообщает используемому протоколу о завершении сеанса сетевого взаимодействия, оставляя, тем не менее, дескрипторы гнезд в неприкосновенности. Освобождается дескриптор гнезда только в результате выполнения функции close.

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

getsockname(sd,name,length);

Функции getsockopt и setsockopt получают и устанавливают значения различных связанных с гнездом параметров в соответствии с типом домена и протокола.

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

-------------------------------------------------------------¬

¦ #include <sys/types.h> ¦

¦ #include <sys/socket.h> ¦

¦ ¦

¦ main() ¦

¦ { ¦

¦ int sd,ns; ¦

¦ char buf[256]; ¦

¦ struct sockaddr sockaddr; ¦

¦ int fromlen; ¦

¦ ¦

¦ sd = socket(AF_UNIX,SOCK_STREAM,0); ¦

¦ ¦

¦ /* имя гнезда - не может включать пустой символ */ ¦

¦ bind(sd,"sockname",sizeof("sockname") - 1); ¦

¦ listen(sd,1); ¦

¦ ¦

¦ for (;;) ¦

¦ { ¦

¦ ¦

¦ ns = accept(sd,&sockaddr,&fromlen); ¦

¦ if (fork() == 0) ¦

¦ { ¦

¦ close(sd); ¦

¦ read(ns,buf,sizeof(buf)); ¦

¦ printf("сервер читает '%s'\n",buf); ¦

¦ exit(); ¦

¦ } ¦

¦ close(ns); ¦

¦ } ¦

¦ } ¦

L------------------------------------------------------------

Рисунок 11.20. Процесс-сервер в домене "UNIX system"

-------------------------------------------------------------¬

¦ #include <sys/types.h> ¦

¦ #include <sys/socket.h> ¦

¦ ¦

¦ main() ¦

¦ { ¦

¦ int sd,ns; ¦

¦ char buf[256]; ¦

¦ struct sockaddr sockaddr; ¦

¦ int fromlen; ¦

¦ ¦

¦ sd = socket(AF_UNIX,SOCK_STREAM,0); ¦

¦ ¦

¦ /* имя в запросе на подключение не может включать ¦

¦ /* пустой символ */ ¦

¦ if (connect(sd,"sockname",sizeof("sockname") - 1) == -1)¦

¦ exit(); ¦

¦ ¦

¦ write(sd,"hi guy",6); ¦

¦ } ¦

L------------------------------------------------------------

Рисунок 11.21. Процесс-клиент в домене "UNIX system"

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

Если сервер обслуживает процессы в сети, указание о том, что гнездо принадлежит домену "Internet", можно сделать следующим образом:

socket(AF_INET,SOCK_STREAM,0);

и связаться с сетевым адресом, полученным от сервера. В системе BSD имеются библиотечные функции, выполняющие эти действия. Второй параметр вызываемой клиентом функции connect содержит адресную информацию, необходимую для идентификации машины в сети (или адреса маршрутов посылки сообщений через промежуточные машины), а также дополнительную информацию, идентифицирующую приемное гнездо машины-адресата. Если серверу нужно одновременно следить за состоянием сети и выполнением локальных процессов, он использует два гнезда и с помощью функции select определяет, с каким клиентом устанавливается связь в данный момент.

Система UNIX поддерживает широкий спектр вычислительных сетей. Традиционные методы согласования протоколов в сильной степени полагаются на помощь системной функции ioctl, однако в разных типах сетей они реализуются по-разному. В системе BSD имеются системные функции для работы с гнездами, поддерживающие более универсальную структуру сетевого взаимодействия. В будущем в версию V предполагается включить описанный в главе 10 потоковый механизм, повышающий согласованность работы в сети.

1. Что произойдет в том случае, если в программе debug будет отсутствовать вызов функции wait (Рисунок 11.3) ? (Намек: возможны два исхода.)
2. С помощью функции ptrace отладчик считывает данные из пространства трассируемого процесса по одному слову за одну операцию. Какие измене- ния следует произвести в ядре операционной системы для того, чтобы уве- личить количество считываемых слов ? Какие изменения при этом необходи- мо сделать в самой функции ptrace ?
3. Расширьте область действия функции ptrace так, чтобы в качестве пара- метра pid можно было указывать идентификатор процесса, не являющегося потомком текущего процесса. Подумайте над вопросами, связанными с защи- той информации: При каких обстоятельствах процессу может быть позволено читать данные из адресного пространства другого, произвольного процесса ? При каких обстоятельствах разрешается вести запись в адресное прост- ранство другого процесса ?
4. Организуйте из функций работы с сообщениями библиотеку пользовательско- го уровня с использованием обычных файлов, поименованных каналов и эле- ментов блокировки. Создавая очередь сообщений, откройте управляющий файл для записи в него информации о состоянии очереди; защитите файл с помощью средств захвата файлов и других удобных для вас механизмов. По- сылая сообщение данного типа, создавайте поименованный канал для всех сообщений этого типа, если такого канала еще не было, и передавайте со- общение через него (с подсчетом переданных байт). Управляющий файл дол- жен соотносить тип сообщения с именем поименованного канала. При чтении сообщений управляющий файл направляет процесс к соответствующему поиме- нованному каналу. Сравните эту схему с механизмом, описанным в настоя- щей главе, по эффективности, сложности реализации и функциональным воз- можностям.
5. Какие действия пытается выполнить программа, представленная на Рисунке 11.22 ?
6. Напишите программу, которая подключала бы область разделяемой памяти слишком близко к вершине стека задачи и позволяла бы стеку при увеличе- нии пересекать границу разделяемой области. В какой момент произойдет фатальная ошибка памяти ?
7. Используйте в программе, представленной на Рисунке 11.14, флаг IPC_NOWAIT, реализуя условный тип семафора. Продемонстрируйте, как за счет этого можно избежать возникновения взаимных блокировок.
8. Покажите, как операции над семафорами типа P и V реализуются при работе с поименованными каналами. Как бы вы реализовали операцию P условного типа ?
9. Составьте программы захвата ресурсов, использующие

(а) поименованные каналы,

(б) системные функции creat и unlink,

(в) функции обмена сооб- щениями. Проведите сравнительный анализ их эффективности.

10. На практических примерах работы с поименованными каналами сравните эф- фективность использования функций обмена сообщениями, с одной стороны, с функциями read и write, с другой.
11. Сравните на конкретных программах скорость передачи данных при работе с разделяемой памятью и при использовании механизма обмена сообщениями. Программы, использующие разделяемую память, для синхронизации заверше- ния операций чтения-записи должны опираться на семафоры.

-------------------------------------------------------------¬

¦ #include <sys/types.h> ¦

¦ #include <sys/ipc.h> ¦

¦ #include <sys/msg.h> ¦

¦ #define ALLTYPES 0 ¦

¦ ¦

¦ main() ¦

¦ { ¦

¦ struct msgform ¦

¦ { ¦

¦ long mtype; ¦

¦ char mtext[1024]; ¦

¦ } msg; ¦

¦ register unsigned int id; ¦

¦ ¦

¦ for (id = 0; ; id++) ¦

¦ while (msgrcv(id,&msg,1024,ALLTYPES,IPC_NOWAIT) > 0)¦

¦ ; ¦

¦ } ¦

L------------------------------------------------------------