Механизмы межпроцессных взаимодействий в операционной системе Unix статья по информатике , Руководство, Проектов, Исследование из Информатика

Скачай Механизмы межпроцессных взаимодействий в операционной системе Unix статья по информатике и еще Руководство, Проектов, Исследование в формате PDF Информатика только на Docsity! Механизмы межпроцессных взаимодействий в операционной системе Unix Сергей Кузнецов Возникшие проблемы Избыточный набор системных средств, предназначенных для обеспечения возможности взаимодействия и синхронизации процессов, которые не обязательно связаны отношением родства IPC - Inter-Process Communication Facilities с появлением UNIX System V Release 4.0 все эти средства были узаконены и вошли в фактический стандарт ОС UNIX современного образца в разных вариантах системы средства IPC реализуются по-разному эффективность реализации различается усложняется разработка мобильных асинхронных программных комплексов Пакет средств IPC UNIX System V Release 3.0 средства, обеспечивающие возможность наличия общей памяти между процессами (сегменты разделяемой памяти - shared memory segments) средства, обеспечивающие возможность синхронизации процессов при доступе с совместно используемым ресурсам, например, к разделяемой памяти (семафоры - semaphores) средства, обеспечивающие возможность посылки процессом сообщений другому произвольному процессу (очереди сообщений - message queues) Общие свойства всех трех механизмов: для каждого механизма поддерживается общесистемная таблица, элементы которой описывают всех существующих в данный момент представителей механизма (конкретные сегменты, семафоры или очереди сообщений) элемент таблицы содержит некоторый числовой ключ, который является выбранным пользователем именем представителя соответствующего механизма процесс, желающий начать пользоваться одним из механизмов, обращается к системе с системным вызовом из семейства "get", ответным параметром является числовой дескриптор ключ IPC_PRIVATE ключ IPC_CREAT защита доступа основывается на тех же принципах, что и защита доступа к файлам Разделяемая память shmget создает новый сегмент разделяемой памяти или находит существующий сегмент с тем же ключом shmat подключает сегмент с указанным дескриптором к виртуальной памяти обращающегося процесса shmdt отключает от виртуальной памяти ранее подключенный к ней сегмент с указанным виртуальным адресом начала shmctl служит для управления параметрами, связанными с существующим сегментом После подключения сегмента разделяемой памяти к виртуальной памяти процесса, он может обращаться к соответствующим элементам памяти с использованием обычных машинных команд чтения и записи shmid = shmget(key, size, flag); size определяет желаемый размер сегмента в байтах если в таблице разделяемой памяти находится элемент, содержащий заданный ключ, и права доступа не противоречат текущим характеристикам процесса, то значением системного вызова является дескриптор существующего сегмента реальный размер сегмента можно узнать с помощью системного вызова shmctl иначе создается новый сегмент с размером не меньше установленного в системе минимального размера сегмента разделяемой памяти и не больше установленного максимального размера создание сегмента не означает немедленного выделения под него основной памяти откладывается до выполнения первого системного вызова подключения сегмента к виртуальной памяти некоторого процесса при выполнении последнего системного вызова отключения сегмента от виртуальной памяти соответствующая основная память освобождается virtaddr = shmat(id, addr, flags); id - это ранее полученный дескриптор сегмента addr - желаемый процессом виртуальный адрес, который должен соответствовать началу сегмента в виртуальной памяти virtaddr - реальный виртуальный адрес начала сегмента не обязательно совпадает со значением прямого параметра addr если addr == 0, ядро выбирает наиболее удобный виртуальный адрес начала сегмента shmdt(addr); addr - виртуальный адрес начала сегмента в виртуальной памяти, ранее полученный от системного вызова shmat shmctl(id, cmd, shsstatbuf); cmd идентифицирует требуемое конкретное действие важна функция уничтожения сегмента разделяемой памяти Семафоры Обобщение классического механизма семафоров общего вида Диекстры Целесообразность обобщения сомнительна Обычно использовался облегченный вариант двоичных семафоров Известен алгоритм реализации семафоров общего вида на основе двоичных Семафор в ОС UNIX: значение семафора идентификатор процесса, который хронологически последним работал с семафором число процессов, ожидающих увеличения значения семафора число процессов, ожидающих нулевого значения семафора Три системных вызова: msgsnd(msgqid, msg, count, flag); msg - это указатель на структуру, содержащую целочисленный тип сообщения и символьный массив count - задает размер сообщения в байтах flag определяет действия ядра при выходе за пределы допустимых размеров внутренней буферной памяти Условия успешной постановки сообщения в очередь: процесс должен иметь право на запись в очередь длина сообщения не должна превосходить верхний предел общая длина сообщений не должна превосходить установленного предела тип сообщения должен быть положительным целым числом Процесс продолжает свое выполнение Ядро активизирует (пробуждает) все процессы, ожидающие поступления сообщений из очереди Превышается верхний предел суммарной длины сообщений обратившийся процесс откладывается до разгрузки очереди но есть флаг IPC_NOWAIT (как для семафоров) count = msgrcv(id, msg, maxcount, type, flag); msg - указатель на структуру данных в адресном пространстве пользователя для размещения принятого сообщения maxcount - размер области данных (массива байтов) в структуре msg type специфицирует тип сообщения, которое желательно принять flag указывает ядру, что следует предпринять, если в указанной очереди сообщений отсутствует сообщение с указанным типом count - реальное число байтов, переданных пользователю Значением параметра type является нуль выбирается первое сообщение копируется в заданную пользовательскую структуру данных процессы, отложенные по причине переполнения очереди сообщений, активизируются если значение параметра maxcount оказывается меньше реального размера сообщения, ядро не удаляет сообщение из очереди и возвращает код ошибки если задан флаг MSG_NOERROR, то выборка сообщения производится, и в буфер пользователя переписываются первые maxcount байтов сообщения Значение type есть положительное целое число выбирается первое сообщение с таким же типом Значение type есть отрицательное целое число выбирается первое сообщение, значение типа которого меньше или равно абсолютному значению type В очереди отсутствуют сообщения, соответствующие спецификации type процесс откладывается до появления в очереди требуемого сообщения но есть флаг IPC_NOWAIT msgctl(id, cmd, mstatbuf); опрос состояния описателя очереди сообщений изменение его состояния уничтожение очереди сообщений Программные каналы Создание неименованного программного канала pipe(fdptr); fdptr - это указатель массива из двух целых чисел для размещения дескриптора для чтения из программного канала (с помощью read) и записи в программный канал (с помощью write) обычные дескрипторы файлов два элемента таблицы открытых файлов процесса Создание именованных программных каналов (или получение доступа к существующим) Обычный системный вызов open если канал открывается на запись, и ни один процесс не открыл его для чтения, то процесс блокируется до тех пор, пока некоторый процесс не откроет этот канал для чтения аналогично обрабатывается открытие для чтения имеется флаг NO_DELAY Запись и чтение: read и write при записи данные помещаются в начало канала при чтении выбираются из конца канала возможны откладывания процессов Окончание работы процесса: close при выполнении последнего закрытия канала по записи все процессы, ожидающие чтения из программного канала, активизируются с возвратом кода ошибки из системного вызова Программные гнезда (sockets) Поддерживаемый ядром механизм, скрывающий особенности сетевой среды и позволяющий единообразно взаимодействовать процессам выполняющимся на одном компьютере в пределах одной локальной сети разнесенным на разные компьютеры территориально распределенной сети Первое решение: UNIX BSD 4.1 в 1982 г. Три составляющих: компонент уровня программных гнезд (независящий от сетевого протокола и среды передачи данных) компонентом протокольного уровня (независящий от среды передачи данных) компонентом уровня управления сетевым устройством Одна из возможных конфигураций программных гнезд Допустимые комбинации протоколов и драйверов задаются при конфигурации системы во время работы системы менять нельзя По духу организация программных гнезд близка к идее потоков Но менее гибкая схема не допускает изменения конфигурации "на ходу" Взаимодействие процессов основано на модели "клиент-сервер" процесс-сервер "слушает (listens)" свое программное гнездо процесс-клиент пытается общаться с процессом-сервером через другое программное гнездо