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

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

Другой способ установки соединения MPI

IN	fd	Дескриптор файла сокета
OUT	intercomm	Новый интеркоммуникатор (дескриптор)

int MPI_Comm_join(int fd, MPI_Comm *intercomm)




MPI_COMM_JOIN(FD, INTERCOMM. IERROR)


INTEGER FD, INTERCOMM, IERROR




static MPI::Intercomm MPI::Comm::Join(const int fd)

MPI_COMM_JOIN предназначен для реализаций MPI, которые существуют для сред, поддерживающих интерфейс сокетов Berkeley [18, 21]. Реализации, которые существуют для сред, поддерживающих интерфейс сокетов Berkeley должны предоставлять точку входа для MPI_COMM_JOIN и возвращать MPI_COMM_NULL.

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

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

Совет разработчикам: Высококачественная реализация должна пытаться установить соединение через медленную среду, если предпочтительная среда не доступна. Если реализации не делают этого, они должны документировать, почему они не могут осуществить соединение MPI через среду, используемую сокетом (особенно, если сокет является соединением по TCP).[]

fd является дескриптором файла, представляющим сокет типа SOCK_STREAM (двустороннее надежное байтовое соединение). Сокету не должны разрешаться неблокирующий ввод-вывод и асинхронное напоминание через SIGIO. Сокет должен находиться в присоединенном состоянии. При вызове MPI_COMM_JOIN сокет должен находиться в состоянии покоя (см. ниже). Приложение должно создавать сокет с использованием стандартных вызовов API сокетов.

MPI_COMM_JOIN должен вызываться процессом на обеих сторонах сокета. Он не завершается, пока оба процесса не вызовут MPI_COMM_JOIN. Два процесса называются локальным и удаленным процессами.

MPI использует сокет для начальной загрузки и создания интеркоммуникатора, и больше ни для чего. До возврата из MPI_COMM_JOIN дескриптор файла является открытым и находится в покое (см. ниже).

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

Сокет должен находиться в состоянии покоя перед вызовом MPI_COMM_JOIN и после возврата из него. Более конкретно, при входе в MPI_COMM_JOIN, read для сокета не должен считывать любые данные, которые были записаны в сокет, пока удаленный процесс не вызовет MPI_COMM_JOIN. При выходе из MPI_COMM_JOIN read для сокета не должен считывать любые данные, которые были записаны в сокет, пока удаленный процесс не покинет MPI_COMM_JOIN. На приложении лежит ответственность убедиться в выполнении первого условия, а на реализации MPI - убедиться в выполнении второго. В многопоточном приложении приложение либо должно убедиться, что один из потоков не выполняет доступ к сокету, когда другой вызывает MPI_COMM_JOIN, или они должны вызывать MPI_COMM_JOIN параллельным способом.

Совет пользователям: MPI волен использовать любые доступные пути связи для сообщений MPI в новом коммуникаторе; сокет используется только для начального согласования.[]

MPI_COMM_JOIN использует для выполнения своей работы не-MPI связь. Взаимодействие не-MPI соединения с незавершенным соединением MPI не определено. Поэтому, результат вызова
MPI_COMM_JOIN для двух соединенных процессов (см. раздел 3.5.4 об определении ``соединенный'') не определен.

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

Партнёры:

Хостинг: