Вызов send, описанный в разделе 3.2.1, является блокирующим: он не возвращает управления до тех пор, пока данные и атрибуты сообщения надежно не сохранены в другом месте, чтобы процесс-отправитель мог обращаться к буферу посылки и перезаписывать его. Сообщение может быть скопировано прямо в соответствующий приемный буфер или во временный системный буфер.
Буферизация сообщения связывает операции посылки и приема. Блокирующая передача может завершаться сразу после буферизации сообщения, даже если приемник не выполнил соответствующего приема. С другой стороны, буферизация сообщения может оказаться дорогой, так как она вовлекает дополнительное копирование память-память, и это требует выделения памяти для буферизации. MРI имеет выбор из нескольких коммуникационных режимов, которые позволяют управлять выбором коммуникационного протокола.
Вызов send, описанный в разделе 3.2.1, использует стандартный (standart) коммуникационный режим. В этом режиме решение о том, будет ли исходящее сообщение буферизовано или нет, принимает MРI. MРI может буферизовать исходящее сообщение. В таком случае операция посылки может завершиться до того, как будет вызван соответствующий прием. С другой стороны, буферное пространство может отсутствовать или MРI может отказаться от буферизации исходящего сообщения из-за ухудшения характеристик обмена. В этом случае вызов send не будет завершен, пока данные не будут перемещены в процесс-получатель.
Следовательно, в стандартном режиме посылка может стартовать вне зависимости от того, выполнен ли соответствующий прием. Она может быть завершена до окончания приема. Посылка в стандартном режиме является нелокальной операцией: она может зависеть от условий приема.
Объяснение: Нежелание разрешать в стандартном режиме буферизацию проистекает от стремления сделать программы переносимыми. Поскольку рано или поздно при повышении размера сообщения в любой системе буферных ресурсов окажется недостаточно, MPI констатирует, что правильная (и, следовательно, переносимая) программа не должна зависеть в стандартном режиме от системной буферизации. Буферизация может улучшить характеристики правильной программы, но она не влияет на результат выполнения программы. Если пользователь может гарантированно предоставить определенный объем буферного пространства, можно использовать поддерживаемую пользователем буферную систему из раздела 3.6 совместно с передачей в буферизованном режиме.[]
Существует три дополнительных коммуникационных режима.
Буферизованный (buffered) режим операции посылки может стартовать вне зависимости от того, инициирован ли соответствующий прием. Однако, в отличие от стандартной посылки, эта операция является локальной и ее завершение не зависит от обстоятельств приема. Следовательно, если посылка выполнена и никакого соответствующего приема не инициировано, тогда MPI обязан буферизовать исходящее сообщение, чтобы позволить завершиться вызову send. Если не имеется достаточного объема буферного пространства, возникнет ошибка. Объем буферного пространства задается пользователем (см. раздел 3.6). Для того, чтобы буферизованный режим был эффективным, может потребоваться распределение буферов пользователем.
Посылка, которая использует синхронный (synchronous) режим, может стартовать вне зависимости от того, был ли начат соответствующий прием. Однако, посылка будет завершена успешно, только если соответствующая операция приема стартовала. Следовательно, завершение синхронной передачи не только указывает, что буфер отправителя может быть повторно использован, но также и отмечает, что получатель достиг определенной точки в своей работе, а именно, что он начал выполнение приема. Если и посылка, и прием являются блокирующими операциями, тогда использование синхронного режима обеспечивает синхронную коммуникационную семантику: посылка не завершается на любой стороне обмена, пока оба процесса не выполнят рандеву в процессе операции обмена. Выполнение обмена в этом режиме является нелокальным.
Посылка, которая использует режим обмена по готовности (ready communication mode), может быть запущена только тогда, когда прием уже инициирован. В противном случае операция является ошибочной и результат будет неопределенным. На некоторых системах обмен по готовности позволяет устранить необходимость в рандеву, что улучшает характеристики обмена. Завершение операции посылки не зависит от состояния приема и в основном указывает, что буфер посылки может быть повторно использован. Операция посылки, которая использует режим готовности, имеет ту же семантику, как и стандартная или синхронная передача; это означает, что отправитель обеспечивает систему дополнительной информацией (а именно, что прием уже инициирован), которая может уменьшить накладные расходы. Вследствие этого в правильной программе посылка по готовности может быть замещена стандартной передачей без влияния на поведение программы (но не на характеристики).
Для трех дополнительных коммуникационных режимов используются три дополнительные функции передачи. Коммуникационный режим отмечается одной префиксной буквой: B - для буферизованного, S - для синхронного и R - для режима готовности.
Синтаксис функции MPI_BSEND представлен ниже.
MPI_BSEND(buf, count, datatype, dest, tag, comm)
| IN | buf | начальный адрес буфера посылки (альтернатива) | |
| IN | count | число элементов в буфере посылки (неотрицательное целое) | |
| IN | datatype | тип данных каждого элемента в буфере посылки (дескриптор) | |
| IN | dest | номер процесса-получателя (целое) | |
| IN | tag | тэг сообщения (целое) | |
| IN | comm | коммуникатор (дескриптор) |
int MPI_Bsend (void* buf, int count, MPI_Datatype datatype,
int dest, int tag, MPI_Comm comm)
MPI_BSEND(BUF, COUNT, DATATYPE, DEST, TAG, COMM, IERROR)
<type> BUF(*)
INTEGER COUNT, DATATYPE, DEST, TAG, COMM, IERROR
void MPI::Comm::Bsend(const void* buf, int count,
const MPI::Datatype& datatype, int dest, int tag) const
Синтаксис функции MPI_SSEND представлен ниже.
MPI_SSEND (buf, count, datatype, dest, tag, comm)
| IN | buf | начальный адрес буфера посылки (альтернатива) | |
| IN | count | число элементов в буфере посылки (неотрицательное целое) | |
| IN | datatype | тип данных каждого элемента в буфере посылки (дескриптор) | |
| IN | dest | номер процесса-получателя (целое) | |
| IN | tag | тэг сообщения (целое) | |
| IN | comm | коммуникатор (дескриптор) |
int MPI_Ssend(void* buf, int count, MPI_Datatype datatype,
int dest, int tag, MPI_Comm comm)
MPI_SSEND(BUF, COUNT, DATATYPE, DEST, TAG, COMM, IERROR)
<type> BUF(*)
INTEGER COUNT, DATATYPE, DEST, TAG, COMM, IERROR
void MPI::Comm::Ssend(const void* buf, int count,
const MPI::Datatype& datatype, int dest, int tag) const
Синтаксис функции MPI_RSEND представлен ниже.
MPI_RSEND (buf, count, datatype, dest, tag, comm)
| IN | buf | начальный адрес буфера посылки (альтернатива) | |
| IN | count | число элементов в буфере посылки (неотрицательное целое) | |
| IN | datatype | тип данных каждого элемента в буфере посылки (дескриптор) | |
| IN | dest | номер процесса-получателя (целое) | |
| IN | tag | тэг сообщения (целое) | |
| IN | comm | коммуникатор (дескриптор) |
int MPI_Rsend(void* buf, int count, MPI_Datatype datatype,
int dest, int tag, MPI_Comm comm)
MPI_RSEND(BUF, COUNT, DATATYPE, DEST, TAG, COMM, IERROR)
<type> BUF(*)
INTEGER COUNT, DATATYPE, DEST, TAG, COMM, IERROR
void MPI::Comm::Rsend(const void* buf, int count,
const MPI::Datatype& datatype, int dest, int tag) const
Имеется только одна операция приема, которая может соответствовать любому режиму передачи. Эта операция блокирования (blocking), описанная в последнем разделе: она завершается только после момента, когда приемный буфер уже содержит новое сообщение. Прием может завершаться перед завершением соответствующей передачи (конечно, он может завершаться только после того, как передача стартует).
В многопоточной реализации MPI система может перепланировать поток, который блокирован на операции отправки или приема, и назначить другой поток для исполнения в том же адресном пространстве. В этом случае вопрос о доступе к буферу обмена или его модификации до завершения обмена решается пользователем. В противном случае результат вычислений не определен.
Объяснение: Когда буфер используется, обращение к нему запрещено, даже если в операции посылки не предполагается изменять содержание этого буфера. Это может показаться излишне строгим, но дополнительное ограничение вызывает небольшую потерю возможностей и дает улучшение характеристик на некоторых системах. Примером является случай, когда передача данных выполняется машиной с DMA, которая не когерентна по кэшу с основным процессом.[]
Совет разработчикам: Возможные коммуникационные протоколы для различных режимов представлены ниже:
Для управления потоками и восстановления ошибок может понадобиться дополнительное управление. Конечно, имеется много других протоколов.
Посылка по готовности может быть реализована как стандартная передача. В этом случае для режима посылки по готовности никаких преимуществ (или потерь) по характеристикам не будет.
Стандартная передача может быть реализована как синхронная. В этом случае не нужна буферизация. Однако, многие (или даже большинство ?) пользователей в определенной степени желают использовать буферизацию.
В многопоточной среде при выполнении блокирующего обмена следует блокировать только выполняемый поток, давая возможность планировщику потоков перепланировать этот поток и поставить на исполнение другой поток.[]