Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
9. Лекция: Методы взаимодействия процессов
В лекции рассматриваются: взаимодействие процессов: проблема ограниченного буфера; проблема "производитель – потребитель"; прямая и косвенная связь процессов; клиент-серверная взаимосвязь; сокетная связь; удаленный вызов процедуры (RPC) и удаленный вызов метода (RMI); выстраивание параметров (marshaling).
Содержание
Введение
Взаимодействие процессов – основа для распараллеленного, эффективного решения задач с помощью группы процессов, координирующих свои действия друг с другом. В лекции рассмотрены некоторые классические схемы взаимодействия процессов при решении типовых задач (например, схема производитель – потребитель), а также виды взаимодействия процессов между собой с помощью передачи сообщений, сокетов, удаленных вызовов процедур и методов.
Независимые и взаимодействующие процессы
С точки зрения взаимосвязи, процессы подразделяются на независимые и взаимодействующие.
Независимый процесс – процесс, никак не связанный с другими процессами, который не может влиять на исполнение других процессов или испытывать их влияние.
Взаимодействующий (совместный) процесс – процесс, который может влиять на исполнение других процессов или испытывать их влияние.
Преимущества взаимодействующих процессов очевидны:
Виды организации взаимосвязи процессов
С точки зрения видов взаимосвязи родительского и дочернего процессов, процессы подразделяются на независимые, подчиненные и сопроцессы.
Подчиненный процесс – процесс, зависящий от процесса-родителя. Подчиненный процесс уничтожается при уничтожении родительского процесса, как в системах UNIX и ОС "Эльбрус". Процесс-родитель перед своим завершением должен ожидать завершения всех своих подчиненных процессов.
Независимый процесс – дочерний процесс, выполняемый независимо от процесса-родителя. Типичные примеры: процессы-демоны в UNIX, запускаемые начальным процессом init. Например, cron – процесс-демон, организующий вызов заданных в специальной таблице crontab действий с заданной периодичностью (автоматическое резервное копирование всех файловых систем на ленту в полночь); smbd – процесс-демон, управляющий серверным программным обеспечением SAMBA для сетевого доступа с Windows-машин к файлам UNIX-машины.
Сопроцесс (coprocess, coroutine) – процесс, равноправно взаимодействующий с другими такими же процессами; хранит свое текущее локальное управление (program counter); взаимодействует с другим сопроцессом Q с помощью операций resume (Q). Взаимодействие нескольких сопроцессов друг с другом операторами resume полностью равноправно. Данный механизм взаимодействия принципиально отличается от вызова процедуры. Операция detach (открепить) переводит сопроцесс в пассивное состояние, в котором могут быть доступны только его глобальные данные, но его программа уже завершена и не подлежит повторному запуску. Сопрограммное взаимодействие реализовано в языке СИМУЛА-67, который, как известно, стал родоначальником и объектно-ориентированного подхода.
Классификация процессов, близкая к приведенной в данном разделе, реализована в ОС "Эльбрус".
Парадигма (шаблон) взаимодействия процессов: производитель – потребитель
Реализация взаимодействия процессов может быть основана на одной из классических парадигм (шаблонов), сложившейся за десятилетия развития программирования. В данном разделе рассмотрим одну из наиболее распространенных из парадигм взаимодействия процессов - производитель – потребитель: процесс-производитель (producer) генерирует в некотором буфере информацию, которая используется процессом-потребителем (consumer).
При реализации данной парадигмы возможны схемы с неограниченным и ограниченным буфером, используемым для связи двух процессов.
При реализации следует учесть, что схема с ограниченным буфером, с точки зрения принципов надежных и безопасных вычислений (trustworthy computing, см. "Понятие операционной системы (ОС), цели ее работы. Классификация компьютерных систем"), представляет опасность атаки "переполнение буфера"(buffer overrun) – ошибочного или преднамеренного превышения размера буфера. Чтобы избежать этой уязвимости, при заполнении буфера необходимо проверять его размер.
Реализуем ограниченный буфер следующим образом. Информация хранится в массиве с двумя указателями: in - для считывания и использования очередного элемента информации процессом-потребителем и out - для записи очередного сгенерированного элемента информации процессом-производителем. При считывании из буфера очередной элемент удаляется, и указатель in, соответственно, продвигается. При записи в буфер продвигается указатель out. Для удобства будем считать буфер циклическим, т.е. при его заполнении следующим заполняемым элементом будет нулевой (если он освободился), следующим после него – первый и т.д. Таким образом, процесс-производитель должен вычислять индекс в буфере, по которому он записывает следующий элемент, по формуле (out + 1) % BUFFER_SIZE, где "%" операция взятия остатка от деления. Аналогично, процесс-потребитель должен вычислять индекс следующего элемента информации в буфере по формуле (in + 1) % BUFFER_SIZE. Учтем также две возможных ситуации: переполнение буфера (при генерации производителем числа элементов, большего длины буфера) и исчерпание буфера (в случае, если потребитель взял из буфера последний на данный момент сгенерированный элемент). Чтобы избежать обращения за границы буфера, при переполнении буфера производитель должен будет ждать, пока в буфере не освободится хотя бы один элемент, а при исчерпании буфера должен будет ждать потребитель, пока хотя бы один новый элемент не появится в буфере.
Реализация представления буфера на языке Си может иметь вид:
#define BUFFER_SIZE 1000 /* или другое конкретное значение */
typedef struct {
. . .
} item;
item buffer[BUFFER_SIZE];
int in = 0;
int out = 0;
Реализация схемы алгоритма процесса-производителя имеет вид:
item nextProduced; /* следующий генерируемый элемент */
while (1) { /* бесконечный цикл */
while (((in + 1) % BUFFER_SIZE) == out)
; /* ждать, пока буфер переполнен */
buffer[in] = nextProduced; /* генерация элемента */
in = (in + 1) % BUFFER_SIZE;
}
Соответственно, реализация процесса-потребителя будет иметь вид:
item nextConsumed; /* следующий используемый элемент */
while (1) { /* бесконечный цикл */
while (in == out)
; /* ждать, пока буфер пуст */
nextConsumed = buffer[out]; /* использование элемента */
out = (out + 1) % BUFFER_SIZE;
}
Данный код может быть использован как шаблон (pattern) для реализации схемы производитель – потребитель в любой системе.
Коммуникация процессов
Рассмотрим теперь возможные механизмы для непосредственной коммуникации процессов и синхронизации их действий.
Наиболее распространенный их них - система сообщений; при этом процессы взаимодействуют между собой без обращений к общим переменным (сравните с алгоритмами производителя и потребителя раздела 9.4).
Средства коммуникации между процессами обеспечивают две операции вида:
Если процессам P и Q требуется взаимодействовать между собой, им необходимо:
Реализация связи может быть физической (общая память, аппаратная шина) или логической (например, логические свойства).
При реализации коммуникационного механизма между процессами необходимо решить следующие вопросы:
Будем использовать данный контрольный список вопросов при анализе различных способов коммуникации процессов.
Непосредственная коммуникация процессов
При непосредственной коммуникации (direct communication) процессы именуют друг друга явно – по именам или по адресам (указателям), которые указываются в вызовах коммуникационных примитивов, например:
При данном способе коммуникации свойства линии связи, согласно контрольному списку раздела 9.5, следующие:
Косвенная коммуникация процессов
При косвенной коммуникации (indirect communication) сообщения направляются и получаются через почтовые ящики (mailboxes), или порты (ports) – системные структуры, предназначенные для приема, хранения и передачи сообщений. Для определенности будем использовать термин почтовый ящик.
Каждый почтовый ящик имеет уникальный идентификатор.
Процессы могут взаимодействовать, только если они имеют общий почтовый ящик.
Свойства линии связи, согласно списку раздела 9.4, в этом случае следующие:
При косвенном способе коммуникации процессы используют набор операций вида:
Основные операции коммуникации принимают вид:
Как мы видим, в данном случае не используются адреса или имена процессов-корреспондентов; вместо них задаются имена почтовых ящиков.
Чтобы лучше осознать суть и особенности данного метода коммуникации, проведем следующую аналогию. Представьте себе очень привычную для Вас электронную почту, которой Вы пользуетесь каждый день. Вы имеете один или несколько почтовых ящиков (email-адресов) и можете послать через любой из них электронное письмо Вашему корреспонденту. При приеме электронной почты Вы обычно задаете режим типа "receive all" (принять все сообщения со всех адресов), т.е. устанавливаете последовательно несколько линий связи с корреспондентами. Аналогичным образом и взаимодействуют процессы при косвенном способе коммуникации. Понятны и возможные проблемы, и способы их решения в обоих случаях: например, если один адрес (почтовый ящик) не работает, можно попытаться послать сообщение через другой. Однако есть и отличия: при отправке электронной почты через некоторый почтовый ящик Вы все же явно указываете email-адрес получателя. С процессами дело обстоит иначе, из-за чего могут возникнуть проблемы.
Вот возможная проблема, возникающая при использовании общего почтового ящика. Пусть процессы P1, P2, и P3 используют почтовый ящик A. P1, посылает сообщение; P2 и P3 принимают. Возникает вопрос: кто (какой из процессов) получает сообщение? Выражаясь более научно, возникает недетерминированная ситуация, что создает ненадежность и небезопасность. Как решить данную проблему? Вот возможные решения:
Очевидно, что каждое из решений имеет свои достоинства и недостатки.
При косвенной связи процессов может оказаться необходимой синхронизация. Дело в том, что передача сообщений может выполняться с блокировкой (синхронно) или без блокировки (асинхронно). Соответственно, основные операции send и receive могут быть с блокировкой или без блокировки.
Буферизация и очередь сообщений
С коммуникационной линией связывается очередь сообщений, реализованная одним из трех возможных способов:
Клиент-серверная взаимосвязь – один из наиболее распространенных видов коммуникации процессов
Используются, в частности, следующие ее разновидности, которые мы и рассмотрим:
Сокеты – наиболее распространенный способ связи клиента и сервера в сети. Впервые они были реализованы в UNIX BSD 4.2. Сокет можно определить как отправную (конечную) точку для коммуникации - endpoint for communication. Сокет создается клиентом для взаимодействия с сервером. Сокет связан с определенным номером порта, через который клиент и сервер обмениваются информацией, используя числовой или символьный последовательный поток. Сервер, со своей стороны, прослушивает порт с заданным номером и создает для этого серверный сокет. По сути дела, сокет можно представлять как конкатенацию IP-адреса и порта. Например, сокет 161.25.19.8:1625 ссылается на порт 1625 на машине (хосте) 161.25.19.8. Коммуникация осуществляется между парой сокетов – клиентским и серверным. Она изображена на рис. 9.1.
Рис. 9.1. Взаимодействие с помощью сокетов.
Удаленные вызовы процедур (Remote Procedure Calls – RPC) впервые предложены фирмой Sun и реализованы в ОС Solaris.
Удаленный вызов процедуры (RPC) – абстракция вызова процедуры между процессами в сетевых системах. Он основан на следующей идее. В клиентской части создаются заглушка (proxy, stub) – локальная процедура, осуществляющая связь с фактической процедурой, находящейся на сервере. Заглушка в клиентской части находит сервер и выстраивает (marshals) параметры для их передачи на сервер по сети. Проблема здесь в том, что адресация на клиенте и на сервере различная, и передавать адрес в памяти каких-либо данных с одного хоста на другой не имеет смысла. Поэтому приходится использовать особую форму передачи информации в виде последовательного потока байтов. Заглушка в серверной части принимает сообщение, распаковывает параметры, преобразует их к нормальному виду и выполняет процедуру на сервере.
Схема организации удаленного вызова процедуры изображена на рис. 9.2.
Рис. 9.2. Исполнение RPC.
Удаленный вызов метода (Remote Method Invocation, RMI) – механизм в Java-технологии, аналогичный RPC, но в объектно-ориентированной форме.
RMI позволяет Java-приложению на одной машине вызвать метод удаленного объекта.
Схема RMI изображена на рис. 9.3.
Рис. 9.3. Удаленный вызов метода в Java.
Схема выстраивания параметров и результатов при удаленных вызовах изображена на рис. 9.4.
Рис. 9.4. Выстраивание параметров при удаленном вызове.
Send – операция отправки сообщения другому процессу.
Receive – операция получения сообщения от другого процесса.
Взаимодействующий (совместный) процесс – процесс, который может влиять на исполнение других процессов или испытывать их влияние.
Выстраивание (marshaling) – механизм преобразования параметров удаленной процедуры (метода) для их передаче по сети в виде последовательного потока.
Косвенная коммуникация (indirect communication) – способ взаимодействия процессов с помощью сообщений, при котором сообщения направляются и получаются через почтовые ящики, или порты.
Независимый процесс – процесс, никак не связанный с другими процессами, который не может влиять на исполнение других процессов или испытывать их влияние.
Непосредственная коммуникация (direct communication) – способ взаимодействия процессов с помощью сообщений, при котором они именуют друг друга явно – по именам или по адресам (указателям), которые указываются в вызовах коммуникационных примитивов.
Очередь сообщений (message queue) – системная структура (буфер) для хранения сообщений между процессами.
Переполнение буфера (buffer overrun) – ошибочное или преднамеренное превышения размера буфера, которое может привести к обращению в чужую область памяти и используется для внешних атак.
Подчиненный процесс – процесс, зависящий от процесса-родителя; уничтожается при уничтожении родительского процесса; процесс-родитель перед своим завершением должен ожидать завершения всех своих подчиненных процессов.
Почтовый ящик (порт) – системная структура, предназначенные для приема, хранения и передачи сообщений.
Производитель – потребитель (producer – consumer) - парадигма взаимодействия процессов, при которой процесс-производитель (producer) генерирует в некотором буфере информацию, которая используется процессом-потребителем (consumer).
Рандеву (rendezvous) – механизм коммуникации процессов, при котором оба процесса приостанавливаются до момента окончания передачи сообщения.
Сокет (socket) – метод клиент-серверного сетевого взаимодействия процессов, при котором информация передается через последовательный поток через порт с определенным номером.
Сопроцесс (coprocess, coroutine) – процесс, равноправно взаимодействующий с другими такими же процессами по управлению с помощью операций типа resume (Q), возобновляющих приостановленный процесс. Переходит в завершенное состояние операцией detach.
Удаленный вызов метода (Remote Method Invocation – RMI) – разработанный фирмой Sun объектно-ориентированный механизм Java-технологии для вызова метода Java на другом компьютере сети, аналогичный удаленному вызову процедуры.
Удаленный вызов процедуры (Remote Procedure Call – RPC) – разработанный фирмой Sun механизм вызова процедуры на другом компьютере локальной сети с использованием процедур-заглушек на клиенте и на сервере, передающих информацию и выстраивающих параметры и результат удаленной процедуры.
Процессы могут быть независимыми друг от друга и взаимодействующими. Преимущества взаимодействующих процессов – совместное использование данных, модульность, ускорение вычислений.
Дочерний процесс по отношению к процессу-родителю может быть подчиненным (зависящим от родителя), независимым, либо сопроцессом. Сопроцессы – равноправная группа процессов, взаимодействующая между собой операторами явного переключения управления.
Парадигма производитель – потребитель – классическая схема взаимодействия процессов: производитель генерирует информационные элементы в буфере, а потребитель использует их и удаляет из буфера. Буфер может быть неограниченным или иметь ограниченную длину.
Коммуникация процессов может осуществляться с помощью сообщений. Коммуникация бывает непосредственная (с явным указанием адресов или имен процессов-адресатов) и косвенная (через почтовые ящики).
При анализе коммуникации процессов весьма важны способ установления связи, число связей между двумя процессами, пропускная способность линии связи, длина сообщений, ненаправленный или двунаправленный (дуплексный) характер связи.
При косвенной связи могут возникнуть проблемы с недетерминизмом при получении сообщений, если несколько процессов используют общий почтовый ящик.
При коммуникации передача сообщений может быть синхронной (с блокировкой) или асинхронной (без блокировки).
С коммуникационной линией связывается очередь сообщений, которая может иметь нулевую длину (процессы взаимодействуют через механизм рандеву), ограниченную или теоретически неограниченную длину.
Основные виды клиент-серверной коммуникации процессов – сокеты, удаленные вызовы процедур и методов.
Сокеты, предназначены для взаимодействия между клиентом и сервером в сетях TCP/IP через порт с определенным номером, при котором информация передается через последовательные потоки.
Удаленный вызов процедуры позволяет вызвать процедуру на другом компьютере локальной сети с использованием процедур-заглушек. осуществляющих выстраивание и передачу параметров и результатов.
Удаленный вызов метода – объектно-ориентированный механизм Java-технологии, аналогичный удаленному вызову процедуры.
Вопросы
Упражнения
Темы для курсовых работ, рефератов, эссе