134 Глава 2. Связь

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

Требование независимости от аппаратного обеспечения постепенно привело к созданию стандарта пересылки сообщений, названному просто интерфейсом передачи сообщений {Message-Passing Interface, MPI). MPI разрабатывался для параллельных приложений, но затем был перенесен на нерезидентное взаимо­действие. Он предполагает использование базовых сетей и не предусматривает ничего, напоминающего коммуникационные серверы (см. рис. 2.19). Кроме того, он предусматривает, что серьезные сбои в системе, такие как аварии процессов или участков сети, фатальны и не могут быть восстановлены автоматически.

MPI предполагает, что связь происходит в пределах известной группы про­цессов. Каждая группа получает идентификатор. Каждый процесс в группе также получает идентификатор (локальный). Пара идентификаторов (groupID, processID), таким образом, однозначно определяет источник или получателя сообщения и используется вместо адреса транспортного уровня. В вычислениях может уча­ствовать несколько, возможно перекрывающихся, групп процессов, исполняе­мых одновременно.

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

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

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

2.4. Связь посредством сообщений 135

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

Также существует и операция передачи с блокировкой, которая называется MPI_send. Ее семантика зависит от реализации. Примитив MPI_send может блоки­ровать отправителя как на время копирования сообщения в исполняющую систе­му MPI на стороне отправителя, так и до момента инициирования получателем операции приема. Первый случай соответствует асинхронной связи, показанной на рис. 2.21, г, второй — на рис. 2.21, д.

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

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

Примитивы MPI_send и MPI_ssend имеют варианты, исключающие необходи­мость копирования сообщения из буфера пользователя во внутренний буфер ло­кальной исполняющей системы MPI. Эти варианты соответствуют асинхронной связи. При помощи примитива MR_isend отправитель передает указатель на со­общение, после чего исполняющая система MPI начинает взаимодействие. От­правитель немедленно продолжает свою работу. Чтобы избежать изменения сообщения до момента окончания связи, MPI предоставляет примитивы для про­верки завершения передачи или, при необходимости, блокировки. Как и в случае MR_send, вопрос о том, нужно ли реально передавать сообщение или достаточно копирования в локальный буфер исполняющей системы MPI, оставлен на ус­мотрение разработчиков.

В случае вызова примитива MR_issend отправитель также передает исполняю­щей системе MPI только указатель. Когда исполняющая система показывает, что она обработала сообщение, отправитель удостоверяется, что получатель получил сообщение и в настоящее время работает с ним.

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

Семантика коммуникационных примитивов MPI не всегда проста, и иногда замена различных примитивов никак не влияет на правильность программы. Официальная причина поддержки такого разнообразия вариантов взаимодейст­вия состоит в том, что разработчики систем MPI должны иметь все возможности для оптимизации производительности. Циники могут сказать, что комитет, как всегда, не нашел в себе сил хорошенько подумать. Интерфейс MPI был разрабо­тан для высокопроизводительных параллельных приложений, что упрощает по­нимание причин подобного разнообразия коммуникационных примитивов.