Ассерты

Аргумент assert в вызовах MPI_WIN_POST, MPI_WIN_START, MPI_WIN_FENCE и MPI_WINLOCK используется для обеспечения соглашений о контексте вызова, которые могут использоваться для оптимизации эффективности. Аргумент assert не изменяет семантику программы, если он предоставляет правильную информацию о программе. В связи с этим является ошибочным предоставлять некорректную информацию. В общем случае пользователи всегда могут определить assert = 0, чтобы указать, что не делается никаких гарантий.

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

Совет разработчикам: Реализации всегда могут игнорировать аргумент assert. Разработчики должны документировать, какие значения assert существенны в их реализациях. []

assert является битовым вектором OR, состоящим из ноль или более следующих integer констант: MPI_MODE_NONCHECK, MPI_MODE_NOSTORE, MPI_MODE_NOPUT, MPI_MODE_NOPRECEDE и
MPI_MODE_NOSUCCEED. Существенные опции перечислены ниже для каждого вызова. []

Совет пользователям: Си/С++ пользователи могут использовать битовый вектор or(|) чтобы объединить эти константы; пользователи ФОРТРАН90 могут использовать битовый вектор ior на системах, которые его поддерживают. В качестве альтернативы, пользователи ФОРТРАНa могут переносимо использовать integer-дополнение к константам or (каждая константа должна появляться в дополнении самое большее один раз!) []

MPI_WIN_START:

MPI_MODE_NOCHECK: соответствующие вызовы MPI_WIN_POST уже выполнились на всех процессах получателях, когда делается вызов MPI_WIN_START. Опция noncheck может определяться в вызове start тогда и только тогда, когда она определена в каждом соответствующем вызове post. Это похоже на оптимизацию ``готов - посылай'', которая может сэкономить хэндшейк (handshake), когда последний неявно присутствует в коде. (Однако, для ``готов-посылай'' имеет место соответствующее регулярное получение, несмотря на то, что start и post должны указать опцию noncheck.)

MPI_WIN_POST:

MPI_MODE_NONCHECK: Соответствующие им вызовы MPI_WIN_START еще не произошли ни на каком инициаторе, когда делается вызов MPI_WIN_POST. Опция noncheck может определяться вызовом post тогда и только тогда, когда она определена каждым соответствующим вызовом start.

MPI_MODENO_STORE: локальное окно не обновлялось локальными stores (или локальными вызовами get или receive) после последней синхронизации. Этим можно избежать необходимости синхронизации кэша при вызове post.

MPI_MODENOPUT: локальное окно не будет обновляться вызовами accumulate или put после вызова post, до следующей (wait) синхронизации. Этим можно избежать необходимости синхронизации кэша при вызове wait.

MPI_WIN_FENCE:

MPI_MODE_NOSTORE: локальное окно не обновлялось локальными stores (или локальными вызовами get или receive) со времени последней синхронизации.

MPI_MODE_NOPUT: локальное окно не будет обновляться вызовами put или accumulate после вызова fence, до следующей синхронизации.

MPI_MODE_NOPRECEDE: fence не завершает какую-либо последовательность локально созданных RMA вызовов. Если этот ассерт создается каким либо одним из процессов в оконной группе, тогда он должен создаваться всеми процессами этой группы.

MPI_MODE_NOCUCCEED: fence не начинает какую либо последовательность локально созданных RMA вызовов. Если этот ассерт создан одним из процессов в оконной группе, тогда он должен создаваться всеми процессами в группе.

MPI_WIN_LOCK:

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

Совет пользователям: Заметим что флаги nostore и noprecede обеспечивают информацию о том, что происходило перед вызовом; флаги noput и nocucceed обеспечивают информацию о том, что произойдет после вызова. []