Массив семафоров IPC

Семафоры представляют собой одну из форм IPC и используются для организации синхронизации взаимодействующих процессов. Рассмотрение функций для работы с семафорами мы начнем традиционно с функции создания/доступа к данному ресурсу — функции semget().

#include <sys/types.h>

#include <sys/ipc.h>

#include <sys/sem.h>

int semget(key_t key, int nsems, int semflag);

Первый параметр функции semget() — ключ, второй — количество семафоров (длина массива семафоров), и третий параметр — флаги. Через флаги можно определить права доступа и те операции, которые должны выполняться (открытие семафора, проверка, и т.д.). Функция semget() возвращает целочисленный идентификатор созданного разделяемого ресурса, либо -1 в случае ошибки. Необходимо отметить, что если процесс подключается к существующему ресурсу, то возможно появление коллизий, связанных с неверным указанием длины массива семафоров.

Основная функция для работы с семафорами — функция semop().

#include <sys/types.h>

#include <sys/ipc.h>

#include <sys/sem.h>

int semop(int semid, struct sembuf *semop, size_t nops);

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

struct sembuf

{

short sem_num; /* номер семафора в массиве */

short sem_op; /* код производимой операции */

short sem_flg; /* флаги операции */

}

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

Если sem_op = 0 то

если val ≠ 0 то

пока (val ≠ 0) [процесс блокирован]

[возврат из вызова]

Если sem_op ≠ 0 то

если val + sem_op < 0 то

пока (val + sem_op < 0) [процесс блокирован]

val = val + sem_op

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

Для управления данным типом разделяемых ресурсов используется системный вызов semctl().

#include <sys/types.h>

#include <sys/ipc.h>

#include <sys/sem.h>

int semctl(int semid, int num, int cmd, union semun arg);

Параметрами данной функции являются, соответственно, дескриптор массива семафоров, индекс семафора в массиве, команда и управляющие параметры. Среди множества команд, которые можно выполнять с помощью данной функции, можно особо отметить две: команду удаления ресурса (IPC_RMID) и команду инициализации и модификации значения семафора (IPC_SET). Используя последнюю команду, можно использовать массив семафоров уже не как средство синхронизации, а как средство передачи информации между взаимодействующими процессами (что само по себе является, как минимум, неэффективным, поскольку семафоры создавались именно как средства синхронизации).

Данная функция возвращает значение, соответствующее выполнявшейся операции (по умолчанию 0), или -1 в случае неудачи. Ниже приводится определение типа последнего параметра.

<sys/sem.h>

union semun

{

int val; /* значение одного семафора */

struct semid_ds *buf; /* параметры массива семафоров в

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

статистика доступа)*/

ushort *array; /* массив значений семафоров */

}

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

/* 1-ый процесс */

#include <stdio.h>

#include <sys/types.h>

#include <sys/ipc.h>

#include <sys/sem.h>

#include <string.h>

#define NMAX 256

int main(int argc, char **argv)

{

key_t key;

int semid, shmid;

struct sembuf sops;

char *shmaddr;

char str[NMAX];

/* создаем уникальный ключ */

key = ftok(“/usr/ter/exmpl”, ’S’);

/* создаем один семафор с определенными правами доступа */

semid = semget(key, 1, 0666 | IPC_CREAT | IPC_EXCL);

/*создаем разделяемую память на 256 элементов */

shmid = shmget(key, NMAX, 0666 | IPC_CREAT | IPC_EXCL);

/* подключаемся к разделу памяти, в shmaddr – указатель на

буфер с разделяемой памятью */

shmaddr = shmat(shmid, NULL, 0);

/* инициализируем семафор значением 0 */

semctl(semid, 0, SETVAL, (int) 0);

sops.sem_num = 0;

sops.sem_flg = 0;

/* запуск цикла */

do

{

printf(“Введите строку:”);

if(fgets(str, NMAX, stdin) == NULL)

/* пишем признак завершения – строку “Q” */

strcpy(str, “Q”);

/* в текущий момент семафор открыт для этого процесса*/

/* копируем строку в разд. память */

strcpy(shmaddr, str);

/* предоставляем второму процессу возможность войти */

sops.sem_op = 3; /* увеличение семафора на 3 */

semop(semid, &sops, 1);

/* ждем, пока семафор будет открыт для 1го процесса –

для следующей итерации цикла*/

sops.sem_op = 0; /* ожидание обнуления семафора */

semop(semid, &sops, 1);

} while (str[0]!= ‘Q’);

/* в данный момент второй процесс уже дочитал из

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

shmdt(shmaddr); /* отключаемся от разделяемой памяти */

/* уничтожаем разделяемую память */

shmctl(shmid, IPC_RMID, NULL);

/* уничтожаем семафор */

semctl(semid, 0, IPC_RMID, (int) 0);

return 0;

}

/* 2-ой процесс */

#include <stdio.h>

#include <sys/types.h>

#include <sys/ipc.h>

#include <sys/sem.h>

#include <string.h>

#define NMAX 256

int main(int argc, char **argv)

{

key_t key;

int semid, shmid;

struct sembuf sops;

char *shmaddr;

char str[NMAX];

/* создаем тот же самый ключ */

key = ftok(“/usr/ter/exmpl”, ’S’);

semid = semget(key, 1, 0666);

shmid = shmget(key, NMAX, 0666);

/* аналогично предыдущему процессу –

инициализация ресурсов */

shmaddr = shmat(shmid, NULL, 0);

sops.sem_num = 0;

sops.sem_flg = 0;

/* запускаем цикл */

do

{

printf(“Waiting...\n”);

/* ожидание на семафоре */

sops.sem_op = -2;

/* будем ожидать, пока “значение семафора” + ”значение

sem_op” не станет неотрицательным, т.е. пока значение

семафора не станет, как минимум, 2 (2 - 2 >= 0) */

semop(semid, &sops, 1);

/* теперь значение семафора равно 1 */

/* критическая секция - работа с разделяемой памятью –

в этот момент первый процесс к разделяемой памяти

доступа не имеет */

/* копируем строку из разд. памяти */

strcpy(str, shmaddr);

if(str[0] == ‘Q’)

/* завершение работы - освобождаем разд. память*/

shmdt(shmaddr);

/* после работы – обнулим семафор */

sops.sem_op = -1;

semop(semid, &sops, 1);

printf(“Read from shared memory: %s\n”, str);

} while (str[0]!= ‘Q’);

return 0;

}

3.3 Сокеты[R24] — унифицированный интерфейс программирования распределенных систем

Средства межпроцессного взаимодействия ОС UNIX, представленные в системе IPC, решают проблему взаимодействия двух процессов, выполняющихся в рамках одной операционной системы. Однако, очевидно, их невозможно использовать, когда требуется организовать взаимодействие процессов в рамках сети. Это связано как с принятой системой именования, которая обеспечивает уникальность только в рамках данной системы, так и вообще с реализацией механизмов разделяемой памяти, очереди сообщений и семафоров, — очевидно, что для удаленного взаимодействия они не годятся. Следовательно, возникает необходимость в каком-то дополнительном механизме, позволяющем общаться двум процессам в рамках сети. При этом механизм должен быть унифицированным: он должен в определенной степени позволять абстрагироваться от расположения процессов и давать возможность использования одних и тех же подходов для локального и нелокального взаимодействия. Кроме того, как только мы обращаемся к сетевому взаимодействию, встает проблема многообразия сетевых протоколов и их использования. Понятно, что было бы удобно иметь какой-нибудь общий интерфейс, позволяющий пользоваться услугами различных протоколов по выбору пользователя.

Обозначенные проблемы был призван решить механизм, впервые появившийся в Берклиевском UNIX — BSD, начиная с версии 4.2, и названный сокетами (sockets). Ниже подробно рассматривается этот механизм.[R25]

Механизм сокетов обеспечивает два типа соединений. Во-первых, это соединение, обеспечивающее установление виртуального канала (т.е. обеспечиваются соответствующие свойства, в частности, гарантируется порядок передачи сообщения), его прямым аналогом является протокол TCP. Во-вторых, это дейтаграммное соединение (соответственно, без обеспечения порядка передачи и т.п.), аналогом которого является протокол UDP.

Именование сокетов для организации работы с ними определяется т.н. коммуникационным доменом. Аппарат сокетов в общем случае поддерживает целый спектр коммуникационных доменов, среди которых нас будут интересовать два из них: домен AF_UNIX (семейство имен в ОС Unix) и AF_INET (семейство имен для сети Internet, определяемое стеком протоколов TCP/IP).

Для создания сокета используется системный вызов socket().

#include <sys/types.h>

#include <sys/socket.h>

int socket(int domain, int type, int protocol);

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

Второй параметр отвечает за тип сокета: либо SOCK_STREAM (тип виртуальный канал), либо SOCK_DGRAM (дейтаграммный тип сокета).

Последний параметр вызова — протокол. Выбор значения данного параметра зависит от многих факторов — и в первую очередь, от выбора коммуникационного домена и от выбора типа сокета. Если указывается нулевое значение этого параметра, то система автоматически выберет протокол, учитывая значения первых аргументов вызова. А можно указать константу, связанную с именем конкретного протокола: например, IPPROTO_TCP для протокола TCP (домена AF_INET) или IPPROTO_UDP для протокола UDP (домена AF_INET). Но в последнем случае необходимо учесть, что могут возникать ошибочные ситуации. Например, если явно выбран домен AF_INET, тип сокета виртуальный канал и протокол UDP, то возникнет ошибка. Однако, если домен будет тем же, тип сокета дейтаграммный и протокол TCP, то ошибки не будет: просто дейтаграммное соединение будет реализовано на выбранном протоколе.

В случае успешного завершения системный вызов socket() возвращает открытый файловый дескриптор, ассоциированный с созданным сокетом. Как отмечалось выше, сокеты представляют собой особый вид файлов в файловой системе ОС Unix. Но данный дескриптор является локальным атрибутом: это лишь номер строки в таблице открытых файлов текущего процесса, в которой появилась информация об этом открытом файле. И им нельзя воспользоваться другим процессам, чтобы организовать взаимодействие с текущим процессом посредством данного сокета. Необходимо связать с этим сокетом некоторое имя, доступное другим процессам, посредством которого они смогут осуществлять взаимодействие. Для организации именования используется системный вызов bind().

#include <sys/types.h>

#include <sys/socket.h>

int bind(int sockfd, struct sockaddr *myaddr, int addrlen);

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

#include <sys/un.h>

struct sockaddr_un

{

short sun_family; /* == AF_UNIX */

char sun_path[108];

};

Первое поле в данной структуре — это код коммуникационного домена, а второе поле — это полное имя. Для домена AF_INET структура выглядит несколько иначе:

#include <netinet/in.h>

struct sockaddr_in

{

short sin_family; /* == AF_INET */

u_short sin_port; /* номер порта */

struct in_addr sin_addr; /* IP-адрес хоста */

char sin_zero[8]; /* не используется */

};

В данной структуре присутствует различная информация, в частности, IP-адрес, номер порта и т.п.

И, наконец, последний аргумент addrlen рассматриваемого системного вызова характеризует размер структуры второго аргумента (т.е. размер структуры sockaddr).

В случае успешного завершения данный вызов возвращает значение 0, иначе — -1.

Механизм сокетов включает в свой состав достаточно разнообразные средства, позволяющие организовывать взаимодействие различной топологии. В частности, имеется возможность организации взаимодействия с т.н. предварительным установлением соединения. Данная модель ориентирована на организацию клиент-серверных систем, когда организуется один серверный узел процессов (обратим внимание, что не процесс, а именно узел процессов), который принимает сообщения от клиентский процессов и их как-то обрабатывает. Общая схема подобного взаимодействия представлена ниже (Рис. 91). Заметим, что тип сокета в данном случае не важен, т.е. можно использовать сокеты, являющиеся виртуальными каналами, так и дейтаграммными.

Рис. 91. Схема работы с сокетами с предварительным установлением соединения.

В данной модели можно выделить две группы процессов: процессы серверной части и процессы клиентской части. На стороне сервера открывается основной сокет. Поскольку необходимо обеспечить возможность другим процессам обращаться к серверному сокету по имени, то в данном случае необходимо связывание сокета с именем (вызов bind()). Затем серверный процесс переводится в т.н. режим прослушивания (посредством системного вызова listen()): это означает, что данный процесс может принимать запросы на соединение с ним от клиентских процессов. При этом, в вызове listen() оговаривается очередь запросов на соединение, которая может формироваться к данному процессу серверной части.

Каждый клиентский процесс создает свой сокет. Заметим, что на стороне клиента связывать сокет необязательно (поскольку сервер может работать с любым клиентом, в частности, и с «анонимным» клиентом). Затем клиентский процесс может передать серверному процессу сообщение, что он с ним хочет соединиться, т.е. передать запрос на соединение (посредством системного вызова connect()). В данном случае возможны три альтернативы.

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

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

И, наконец, в-третьих, может оказаться, что указанная очередь переполнена. В этом случае клиент получает отказ с соответствующим уведомлением, что сервер в данный момент занят.

Итак, данная схема организована таким образом, что к одному серверному узлу может иметь множество соединений. Для организации этой модели имеется системный вызов accept(), который работает следующим образом. При обращении к данному системному вызову, если в очереди имеется необработанная заявка на соединение, создается новый локальный сокет, который связывается с клиентом. После этого клиент может посылать сообщения серверу через этот новый сокет. А сервер, в свою очередь, получая через данный сокет сообщения от клиента, «понимает», от какого клиента пришло это сообщение (т.е. клиент получает некоторое внутрисистемное именование, даже если он не делал связывание своего сокета). И, соответственно, в этом случае сервер может посылать ответные сообщения клиенту.

Завершение работы состоит из двух шагов. Первый шаг заключается в отключении доступа к сокету посредством системного вызова shutdown(). Можно закрыть сокет на чтение, на запись, на чтение-запись. Тем самым системе передается информация, что сокет более не нужен. С помощью этого вызова обеспечивается корректное прекращение работы с сокетом (в частности, это важно при организации виртуального канала, который должен гарантировать доставку посланных данных). Второй шаг заключается в закрытии сокета с помощью системного вызова close() (т.е. закрытие сокета как файла).

Далее эту концептуальную модель можно развивать. Например, сервер может порождать дочерний процесс для каждого вызова accept(), и тогда все действия по работе с данным клиентом ложатся на этот дочерний процесс. На родительский процесс возлагается задача прослушивание «главного» сокета и обработка поступающих запросов на соединение. Вот почему речь идет не об одном процессе сервере, а о серверном узле, в котором может находиться целый набор процессов.

Теперь рассмотрим модель сокетов без предварительного соединения. В этой модели используются лишь дейтаграммные сокеты. В отличие от предыдущей модели, которая была иерархически организованной, то эта модель обладает произвольной организацией взаимодействия. Это означает, что в данной модели у каждого взаимодействующего процесса имеется сокет, через который он может получать информацию от различных источников в отличие от предыдущей модели, где имеется «главный» известный всем клиентам сокет сервера, через который неявно передается управляющая информация (заказы на соединение), а затем с каждым клиентом связывается один локальный сокет. Этот механизм позволяет серверу взаимодействовать с клиентом, не зная его имя явно. В текущей модели ситуация симметричная: любой процесс через свой сокет может послать информацию любому другому сокету. Это означает, что механизм отправки имеет соответствующую адресную информацию (т.е. информацию об отправителе и получателе).

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

Далее будут более подробно рассмотрены упомянутые системные вызовы для работы с сокетами.

Для посылки запроса на соединение используется системный вызов connect().

#include <sys/types.h>

#include <sys/socket.h>

int connect(int sockfd, struct sockaddr *serv_addr,

int addrlen);

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

В случае успешного завершения вызов возвращает значение 0, иначе возвращается -1, а в переменную errno заносится код ошибки.

Для перехода серверного процесса в режим прослушивания сокета используется системный вызов listen().

#include <sys/types.h>

#include <sys/socket.h>

int listen(int sockfd, int backlog);

Параметры вызова — дескриптор сокета и максимальный размер очереди необработанных запросов на соединение. В случае успешного завершения вызов возвращает значение 0, иначе возвращается -1, а в переменную errno заносится код ошибки.

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

#include <sys/types.h>

#include <sys/socket.h>

int accept (int sockfd, struct sockaddr *addr,

int *addrlen);

Первый параметр данной функции — дескриптор «главного» сокета. Второй параметр — указатель на структуру, в которой возвращается адрес клиентского сокета, с которым установлено соединение (если адрес клиента не интересует, передается NULL). В последнем параметре возвращается реальная длина упомянутой структуры.

Для модели с предварительным установлением соединения можно использовать системные вызовы чтения и записи в файл — соответственно, read() и write() (в качестве параметра этим функциям передается дескриптор сокета), а также системные вызовы send() (посылка сообщения) и recv() (прием сообщения).

#include <sys/types.h>

#include <sys/socket.h>

int send(int sockfd, const void *msg, int msglen,

unsigned int flags);

int recv(int sockfd, void *buf, int buflen, unsigned int flags);

Параметры: sockfd — дескриптор сокета, через который передаются данные; msg — указатель на начало сообщения; msglen — длина посылаемого сообщения; buf — указатель на буфер для приема сообщения; buflen — первоначальный размер буфера; и, наконец, параметр flags может содержать комбинацию специальных опций. Например:

- MSG_OOB — флаг сообщает ОС, что процесс хочет осуществить прием/передачу экстренных сообщений;

- MSG_PEEK — при вызове recv() процесс может прочитать порцию данных, не удаляя ее из сокета. Последующий вызов recv() вновь вернет те же самые данные.

Для организации приема и передачи сообщений в модели без предварительного установления соединения (Рис. 92)используется пара системных вызовов sendto() и recvfrom().

#include <sys/types.h>

#include <sys/socket.h>

int sendto(int sockfd, const void *msg,

int msglen, unsigned int flags,

const struct sockaddr *to, int tolen);

int recvfrom(int sockfd, void *buf,

int buflen, unsigned int flags,

struct sockaddr *from, int *fromlen);

Первые четыре параметра каждого из вызовов имеют ту же семантику, что и параметры вызовов send() и recv() соответственно. Остальные параметры имеют следующий смысл: to — указатель на структуру, содержащую адрес получателя; tolen — размер структуры to; from — указатель на структуру с адресом отправителя; fromlen — размер структуры from.

Рис. 92. Схема работы с сокетами без предварительного установления соединения.

Для завершения работы с сокетом используется системный вызов shutdown().

#include <sys/types.h>

#include <sys/socket.h>

int shutdown (int sockfd, int mode);

Первый параметр — дескриптор сокета, второй — режим закрытия соединения:

- 0 — сокет закрывается для чтения;

- 1 — сокет закрывается для записи;

- 2 — сокет закрывается и для чтения, и для записи.

Для закрытия сокета используется системный вызов close(), в котором в качестве параметра передается дескриптор сокета.[R26]