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

Модель рандеву требует, чтобы в том случае, когда процесс P₁ хотел бы передать данные процессу P₂, оба процесса должны выразить свою готовность установить связь, выдав заявки на передачу и прием информации соответственно.

Если происходит так, что процесс P₁ выдаст заявку на передачу первым, он должен приостановить свое выполнение до тех пор, пока процесс P₂ не выдаст заявку на получение. Аналогично, если первым заявку на получение информации выдаст процесс P₂, он также приостанавливается, пока не будет получена заявка на передачу от процесса P₁. Когда оба процесса таким образом синхронизируются, происходит передача данных и оба процесса продолжают выполнение. Такую синхронизацию процессов называют рандеву.

Модель рандеву, предложенная Хоаром, реализует взаимодействие процессов “ симметрично ” (оба вступающих в общение партнера обрабатываются одинаково).

В качестве примера можно рассмотреть два взаимодействующих процесса: процесс P₁ передает сообщение S процессу P₂, причем передача выполняется только после того, как оба процесса будут готовы к взаимодействию:

Первый процесс	Второй процесс
process P1; var S:DATA_TYPE; begin ... {Заявка на передачу данных и их передача:} P2!S; ... end;	process P2; var M:DATA_TYPE; begin ... {Заявка на прием данных и их получение:} P1?M; ... end;

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

Для практических языков параллельного программирования это является ограничением, так как становится невозможным написать общий “библиотечный” процесс, который мог бы обслуживать процессы пользователя с неизвестными ему именами.

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

Приведенный выше пример с симметричным рандеву для несимметричных рандеву имел бы вид:

Первый процесс (главный)	Второй процесс (обслуживающий)
process P1; var S:DATA_TYPE; begin... {Вызов процедуры передачи данных:} P2. message (S); ... end;	process P2; var M:DATA_TYPE; begin... {Оператор приема, инициирующий рандеву:} accept message (in X:DATA_TYPE); M:=X; ... end;

Внутри главного процесса данные передаются точно также, как при использовании монитора.

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

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

В организации асимметричных рандеву появились новые моменты:

– передача данных специфицируется параметрами процедуры, следовательно, можно специфицировать любое число параметров, которые могут принадлежать классам in, out или inout, то есть при одном рандеву можно передать более одного сообщения и передача может выполняться в двух направлениях;

– тело оператора приема выполняется как критический участок, что обеспечивает дополнительную гибкость программирования.

Такое определение модели рандеву (принятое за основу при разработке проекта языка Ада) можно назвать определением расширенного рандеву.

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

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

Ниже приведено решение задачи “производитель-потребитель” с организацией доступа процессов к кольцевому буферу с применением модели рандеву.

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

Функционирование процесса, обслуживающего буфер, зависит от оператора выбора select. Этот оператор обеспечивает выбор для выполнения оператора приема. Каждый раз при выполнении оператора выбора имеется четыре возможности:

– есть обращение на чтение;

– есть обращение на запись;

– есть обращение как на чтение, так и на запись;

– нет обращений ни на чтение, ни на запись.

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

Обслуживающий буфер процесс	process BUFFER_MANAGER; var BUFFER: array [ 0.. N - 1] of DATA_TYPE; CURRENT_RECORD: 0.. N - 1; CURRENT_WRITE: 0.. N - 1; CURRENT_READ: 0.. N - 1; NOT_EMPTY, NOT_FULL: boolean; procedure WRITE_RECORD (DATA: DATA_TYPE); {Процедура заполнения одной записи в буфере } begin BUFFER [CURRENT_WRITE]:=DATA; CURRENT_RECORD:=CURRENT_RECORD + 1; CURRENT_WRITE:= (CURRENT_WRITE + 1) mod N; NOT_FULL:= (CURRENT_RECORD <N); end; procedure READ_RECORD (var DATA: DATA_TYPE); {Процедура чтения записи из очередной позиции } {в буфере и ее освобождение } begin DATA:=BUFFER [CURRENT_READ]; CURRENT_RECORD:=CURRENT_RECORD -1; CURRENT_READ:= (CURRENT_READ + 1) mod N; NOT_EMPTY:= (CURRENT_RECORD > 0); end; begin {Инициализация процесса } CURRENT_RECORD:= 0; CURRENT_READ:= 0; CURRENT_WRITE:= 0; NOT_EMPTY:= false; NOT_FULL:= true; {Основной цикл работы процесса:} loop select when NOT_FULL => accept write (in X:DATA_TYPE); WRITE_RECORD (X); end or when NOT_EMPTY => accept read (out X:DATA_TYPE); READ_RECORD (X); end end select end loop end.
Процесс-производитель (“писатель”)	process P1 ; var NEW_REC:DATA_TYPE; begin while true do begin ... produce_next_record (NEW_REC); BUFFER_MANAGER. write (NEW_REC); ... end end P1 .
Процесс-потребитель (“читатель”)	process P2 ; var NEW_REC:DATA_TYPE; begin while true do begin ... BUFFER_MANAGER. read (NEW_REC); process_new_record (NEW_REC); ... end end P2 .

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

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