| |
Аргумент 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
обеспечивают информацию о том, что произойдет после
вызова. []
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |