Введение в распределенные

Примитивы взаимодействия

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

send(void *sendbuf, int count, int dest), где

sendbuf – указывает на буфер, содержащий передаваемые данные, count – содержит количество передаваемых элементов данных, dest – идентифицирует процесс-получатель.

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

receive(void *recvbuf, int count, int source), где


recvbuf – указывает на буфер, сохраняющий принимаемые данные, count – содержит количество принимаемых элементов данных, source – идентифицирует процесс-отправитель.

Для анализа работы команд send() и receive() рассмотрим следующий пример кода, в котором процесс P₁ отправляет сообщение процессу P₂, а процесс P₂ выводит полученное сообщение в стандартный выходной поток.

P1	P2
a = 100; send(&a, 1, 2); a = 0;	receive(&a, 1, 1); printf("%d\n", a);

Стоит обратить внимание, что процесс P₁ изменяет значение переменной "a" сразу после команды send(). Очевидно, что семантика операции send() должна обеспечивать получение процессом P₂ значения 100, а не нуля. Другими словами, процесс P₂ должен получить значение переменной "a" на момент вызова команды send(). В то же время большинство современных компьютерных архитектур доверяют функции приема-передачи данных сетевым интерфейсам и не подразумевают участия центрального процессора (ЦП) в пересылке данных. В результате, если команда send() попросту дает задание коммуникационной подсистеме на отправку данных и сразу же возвращает управление вызвавшему ее процессу, не исключены ситуации, когда процесс P₂ получит значение ноль вместо ожидаемого 100.

Простым решением указанной проблемы является возврат управления в отправляющий процесс P₁ только тогда, когда он не окажет влияния на семантику передачи данных. Важно отметить, что под этим не обязательно подразумевается возвращение в вызвавший процесс только после того, как принимающий процесс получит все передаваемые данные. Это всего лишь означает, что отправитель блокируется до момента, когда выполнение семантики операции send() сможет быть гарантировано вне зависимости от дальнейшего хода выполнения приложения. Существует два механизма обеспечения этого требования.
Блокирующие операции отправки/ получения без буферизации. В этом случае возврат из команды send() не осуществляется до тех пор, пока не будет вызвана соответствующая команда receive() в принимающем процессе и пока все данные не будут переданы процессу-получателю. Подобный механизм взаимодействия обычно подразумевает
дополнительный обмен сигналами для установления связи (англ. handshake) между отправляющим и принимающим процессами. А именно, когда процесс-отправитель достигает состояния готовности к обмену данными, он отправляет запрос на передачу данных процессу-получателю и переходит в состояние ожидания до тех пор, пока не получит от него соответствующего ответа. Процесс-получатель отвечает на данный запрос только после того, как он сам достигнет состояния готовности к приему данных и вызовет команду receive(). Собственно передачу данных процесс- отправитель начинает только после получения ответа от принимающего процесса, что свидетельствует о готовности последнего к приему данных. Описанная схема взаимодействия представлена на рис. 1.7, где А – передающий процесс, а В – принимающий процесс, и носит название блокирующей отправки/ получения без буферизации, т.к. в этом случае не используется никаких дополнительных буферов, как на стороне отправителя, так и на стороне получателя.

(а)

(б)

(в)
Рис. 1.7. Механизм блокирующей отправки/ получения без буферизации;

(а) первым осуществляется вызов send(), (б) вызовы send() и receive() происходят практически одновременно, (в) первым осуществляется вызов receive().

Из рис. 1.7 видно, что блокирующая отправка/ получение без буферизации неплохо работает, когда команды send() и receive() вызываются приблизительно в одно и то же время. Однако в асинхронных системах достичь подобной синхронности в действиях нескольких процессов практически невозможно. Поэтому накладные расходы,

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