Введение и обзор

К операциям коллективного обмена относятся:

• Барьерная синхронизация всех процессов группы (раздел 4.3).
• Широковещательная передача (broadcast) от одного процесса всем остальным процессам группы (раздел 4.1, рис. 4.1)
• Сбор данных из всех процессов группы в один процесс (раздел 4.5, рис. 4.1)
• Рассылка данных одним процессом группы всем процессам группы. (раздел 4.6,

  рис. 4.1)

• Вариант сбора данных, когда все процессы группы получают результат (раздел 4.7). Этот вариант представлен на рис. 4.1 как ``allgather''
• Раздача / сбор данных из всех процессов группы всем процессам группы (раздел 4.8). Этот вариант называется также полным обменом или all-to-all (рис. 4.1)
• Глобальные операции редукции, такие как сложение, нахождение максимума, минимума, или определённые пользователем функции, где результат возвращается всем процессам группы или в один процесс (раздел 4.9).
• Составная операция редукции и раздачи (раздел 4.10).
• Префиксная операция редукции, при которой в процессе i появляется результат редукции 0,1, ..., i, i < n, где n - число процессов в группе (раздел 4.11).

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

Различные коллективные операции, такие как широковещание и сбор данных, имеют единственный процесс-отправитель или процесс-получатель. Такие процессы называются корневыми (root). Некоторые аргументы в коллективных функциях определены как ``существенные только для корневого процесса'' и игнорируются для всех других участников операции.

Информация относительно буферов обмена, основных типов данных и правил приведения типов представлена в главе 3, а информация о группах и коммуникаторах - в главе 5.

Условия соответствия типов для коллективных операций более строгие, чем аналогичные условия для парного обмена. А именно, для коллективных операций количество посланных данных должно точно соответствовать количеству данных, описанных в процессе-получателе.

Однако, допускается различие в картах типов данных у процесса-отправителя и процесса-получателя (раздел 3.12).

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

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

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

Утверждения о синхронизации сделаны так, чтобы позволить различные реализации коллективных функций.

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

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

С другой стороны, корректная переносимая программа должна учитывать факт, что коллективная операция может быть синхронизирована. Нельзя полагаться на этот побочный эффект синхронизации, но необходимо учитывать, что он может иметь место. Это обсуждается в разделе 4.12.[]

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