[ новости /+++ | форум | теги | ]

Каталог документации / Раздел "Программирование, языки" / Оглавление документа

Блокирующий прием

Синтаксис функции блокирующего приема MPI_RECV представлен ниже.

MPI_RECV (buf, count, datatype, source, tag, comm, status)

int MPI_Recv (void* buf, int count, MPI_Datatype datatype,
    int source, int tag, MPI_Comm comm, MPI_Status *status)

MPI_RECV(BUF, COUNT, DATATYPE, SOURCE, TAG, COMM, STATUS, IERROR)
   <type> BUF(*)
   INTEGER COUNT, DATATYPE, SOURCE, TAG, COMM,
   STATUS(MPI_STATUS_SIZE), IERROR

void MPI::Comm::Recv (void* buf, int count, const MPI::Datatype& datatype,
   int source, int tag, MPI::Status& status) const

void MPI::Comm::Recv (void* buf, int count,
   const MPI::Datatype& datatype, int source, int tag) const

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

Совет пользователям: Функция MPI_PROBE, описанная в разделе 3.8, может быть использована для получения сообщений неизвестной длины.[]

Совет разработчикам: Хотя никакого специального поведения для ошибочных программ в MPI не предусмотрено, рекомендуется в случае переполнения возвращать в status информацию об отправителе и тэг входного сообщения. Операция приема возвратит код ошибки. Хорошая реализация MPI должна также гарантировать, что никакая память за пределами буфера приема не будет модифицирована.

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

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

Однако, нельзя задать произвольное значение для comm. Следовательно, сообщение может быть принято, если оно адресовано данному получателю и имеет соответствующий коммуникатор.

Тэг сообщения задается аргументом tag операции приема. Аргумент отправителя, если он отличен от MPI_ANY_SOURCE, задается как номер внутри группы процессов, связанной с тем же самым коммуникатором (удаленная группа для интеркоммуникаторов). Следовательно, диапазон значений для аргумента отправителя находится в пределах {0,..., n-1} {MPI_ANY_SOURCE}, где n - количество процессов в этой группе.

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

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

Совет разработчикам: Контекст сообщения и другая информация о коммуникаторе может быть реализована как дополнительное поле тэга. Оно отличается от обычного тэга сообщения тем, что в этом поле не разрешаются неопределенные номера процессов и что установкой значений этого поля управляют манипуляционные функции коммуникатора.[]

Партнёры:

Хостинг: