Программирование для многопроцессорных систем в стандарте MPI - Шпаковский Г.И., Серикова Н.В.. Программирование для многопроцессорных систем в стандарте MPI -. Организация вычислений в многопроцессорных системах
 Скачать 1.61 Mb.
|
|
3.4. КОММУНИКАЦИОННЫЕ РЕЖИМЫ Вызов send , описанный в параграфе 3.2.1, является блокирующим: он не возвращает управления до тех пор, пока данные и атрибуты со- общения не сохранены в другом месте так, чтобы процесс- отправитель мог обращаться к буферу посылки и перезаписывать его. Сообщение может быть скопировано прямо в соответствующий при- емный буфер или во временный системный буфер. Буферизация сообщения связывает операции посылки и приема. Блокирующая передача может завершаться сразу после буферизации сообщения, даже если приемник не выполнил соответствующий при- 55 ем. С другой стороны, буферизация сообщения может оказаться доро- гой, так как она вовлекает дополнительное копирование память– память, и это требует выделения памяти для буферизации. MРI имеет выбор из нескольких коммуникационных режимов, которые позволя- ют управлять выбором коммуникационного протокола. Стандартный коммуникационный режим используется в вызове send , описанный в параграфе 3.2.1. В этом режиме решение о том, бу- дет ли исходящее сообщение буферизовано или нет, принимает MРI. MРI может буферизовать исходящее сообщение. В таком случае опе- рация посылки может завершиться до того, как будет вызван соответ- ствующий прием. С другой стороны, буферное пространство может отсутствовать или MРI может отказаться от буферизации исходящего сообщения из-за ухудшения характеристик обмена. В этом случае вы- зов send не будет завершен, пока данные не будут перемещены в про- цесс-получатель. В стандартном режиме посылка может стартовать вне зависимости от того, выполнен ли соответствующий прием. Она может быть за- вершена до окончания приема. Посылка в стандартном режиме явля- ется нелокальной операцией: она может зависеть от условий приема. Нежелание разрешать в стандартном режиме буферизацию происхо- дит от стремления сделать программы переносимыми. Поскольку при повышении размера сообщения в любой системе буферных ресурсов может оказаться недостаточно, MPI занимает позицию, что правиль- ная (и, следовательно, переносимая) программа не должна зависеть в стандартном режиме от системной буферизации. Буферизация может улучшить характеристики правильной программы, но она не влияет на результат выполнения программы. Буферизованный режим операции посылки может стартовать вне зависимости от того, инициирован ли соответствующий прием. Однако, в отличие от стандартной посылки, эта операция является ло- кальной, и ее завершение не зависит от приема. Следовательно, если посылка выполнена и никакого соответствующего приема не иниции- ровано, то MPI буферизует исходящее сообщение, чтобы позволить завершиться вызову send . Если не имеется достаточного объема бу- ферного пространства, будет иметь место ошибка. Объем буферного пространства задается пользователем (параграф 3.6). При синхронном режиме посылка может стартовать вне зависи- мости от того, был ли начат соответствующий прием. Посылка будет 56 завершена успешно, только если соответствующая операция приема стартовала. Завершение синхронной передачи не только указывает, что буфер отправителя может быть повторно использован, но также и отмечает, что получатель достиг определенной точки в своей работе, а именно, что он начал выполнение приема. Если и посылка, и прием являются блокирующими операциями, то использование синхронного режима обеспечивает синхронную коммуникационную семантику: посылка не завершается на любой стороне обмена, пока оба процесса не выполнят рандеву в процессе операции обмена. Выполнение обме- на в этом режиме не является локальным. При обмене по готовности посылка может быть запущена только тогда, когда прием уже инициирован. В противном случае операция является ошибочной, и результат будет неопределенным. Завершение операции посылки не зависит от состояния приема и указывает, что буфер посылки может быть повторно использован. Операция посыл- ки, которая использует режим готовности, имеет ту же семантику, как и стандартная или синхронная передача. Это означает, что отправи- тель обеспечивает систему дополнительной информацией (именно, что прием уже инициирован), которая может уменьшить накладные расходы. Вследствие этого в правильной программе посылка по го- товности может быть замещена стандартной передачей без влияния на поведение программы (но не на характеристики). Для трех дополнительных коммуникационных режимов исполь- зуются три дополнительные функции передачи. Коммуникационный режим отмечается одной префиксной буквой: B – для буферизованно- го, S – для синхронного и R – для режима готовности. MPI_BSEND(buf, count, datatype, dest, tag, comm) IN buf начальный адрес буфера посылки (альтернатива) IN count число элементов в буфере посылки (неотрицательное целое) IN datatype тип данных каждого элемента в буфере посылки (дескриптор) IN dest номер процесса-получателя (целое) IN tag тэг сообщения (целое) IN comm коммуникатор (дескриптор) int MPI_Bsend (void* buf, int count, MPI_Datatype datatype, int dest, int tag, MPI_Comm comm) MPI_BSEND(BUF, COUNT, DATATYPE, DEST, TAG, COMM, IERROR) INTEGER COUNT, DATATYPE, DEST, TAG, COMM, IERROR 57 void MPI::Comm::Bsend(const void* buf, int count, const MPI::Datatype& datatype, int dest, int tag) const MPI_SSEND (buf, count, datatype, dest, tag, comm) IN buf начальный адрес буфера посылки (альтернатива) IN count число элементов в буфере посылки (неотрицательное целое) IN datatype тип данных каждого элемента в буфере посылки (дескриптор) IN dest номер процесса-получателя (целое) IN tag тэг сообщения (целое) IN comm коммуникатор (дескриптор) int MPI_Ssend(void* buf, int count, MPI_Datatype datatype, int dest, int tag, MPI_Comm comm) MPI_SSEND(BUF, COUNT, DATATYPE, DEST, TAG, COMM, IERROR) INTEGER COUNT, DATATYPE, DEST, TAG, COMM, IERROR void MPI::Comm::Ssend(const void* buf, int count, const MPI::Datatype& datatype, int dest, int tag) const MPI_RSEND (buf, count, datatype, dest, tag, comm) IN buf начальный адрес буфера посылки (альтернатива) IN count число элементов в буфере посылки (неотрицательное целое) IN datatype тип данных каждого элемента в буфере посылки (дескриптор) IN dest номер процесса-получателя (целое) IN tag тэг сообщения (целое) IN comm коммуникатор (дескриптор) int MPI_Rsend (void* buf, int count, MPI_Datatype datatype, int dest, int tag, MPI_Comm comm) MPI_RSEND(BUF, COUNT, DATATYPE, DEST, TAG, COMM, IERROR) INTEGER COUNT, DATATYPE, DEST, TAG, COMM, IERROR void MPI::Comm::Rsend(const void* buf, int count, const MPI::Datatype& datatype, int dest, int tag) const Имеется только одна операция приема, которая может соответст- вовать любому режиму передачи. Эта операция – блокирующая: она завершается только после того, когда приемный буфер уже содержит новое сообщение. Прием может завершаться перед завершением соот- ветствующей передачи (конечно, он может завершаться только после того, как передача стартует). 58 3.5. СЕМАНТИКА ПАРНОГО ОБМЕНА МЕЖДУ ПРОЦЕССАМИ Правильная реализация MPI гарантирует определенные общие свойства парного обмена. Очередность . Сообщения не обгоняют друг друга: если отправи- тель последовательно посылает два сообщения в один адрес, то они должны быть приняты в том же порядке. Если получатель инициирует два приема последовательно и оба соответствуют тому же сообще- нию, то вторая операция не будет принимать это сообщение, если первая операция все еще не выполнена. Это требование облегчает ус- тановление соответствия посылки и приема. Оно гарантирует, что программа с передачей сообщений детерминирована, если процессы однопоточные и константа MPI_ANY_SOURCE не используется при приеме. Если процесс имеет однопоточное исполнение, тогда любые два обмена, выполняемые этим процессом, упорядочены. Если процесс многопоточный, тогда семантика потокового испол- нения может быть неопределенной относительно порядка для двух операций посылки, выполняемых двумя различными ветвями. Опера- ции логически являются конкурентами, даже если одна физически предшествует другой. Если две операции приема, которые логически конкурентны, принимают два последовательно посланных сообщения, то два сообщения могут соответствовать двум приемам в различном порядке. Пример 3.4. Пример необгоняемых сообщений CALL MPI_COMM_RANK(comm, rank, ierr) IF (rank.EQ.0) THEN CALL MPI_BSEND(buf1, count, MPI_REAL, 1, tag, comm, ierr) CALL MPI_BSEND(buf2, count, MPI_REAL, 1, tag, comm, ierr) ELSE CALL MPI_RECV(buf1,count,MPI_REAL,0,MPI_ANY_TAG,comm,status,ierr) CALL MPI_RECV(buf2, count, MPI_REAL, 0, tag, comm, status, ierr) END IF Сообщение, посланное в первой передаче, обязано быть принято в первом приеме; сообщение, посланное во второй передаче, обязано быть принято во втором приеме. Продвижение обмена . Если пара соответствующих посылки и приема инициализирована двумя процессами, то по крайней мере одна 59 из этих двух операций будет завершена независимо от других дейст- вий в системе: операция посылки будет завершена, несмотря на то, что прием завершен другим сообщением; операция приема будет за- вершена, не глядя на то, что посланное сообщение будет поглощено другим соответствующим приемом, который был установлен на том же самом процессе-получателе. Пример 3.5. Пример двух пересекающихся пар. CALL MPI_COMM_RANK(comm, rank, ierr) IF (rank.EQ.0) THEN CALL MPI_BSEND(buf1, count, MPI_REAL, 1, tag1, comm, ierr) CALL MPI_SSEND(buf2, count, MPI_REAL, 1, tag2, comm, ierr) ELSE ! rank.EQ.1 CALL MPI_RECV(buf1, count, MPI_REAL, 0, tag2, comm, status, ierr) CALL MPI_RECV(buf2, count, MPI_REAL, 0, tag1, comm, status, ierr) END IF Оба процесса начинают первый коммуникационный вызов. По- скольку первая посылка процесса с номером 0 использует буферизо- ванный режим, она обязана завершиться безотносительно к состоя- нию процесса с номером 1. Поскольку никакого соответствующего приема не инициировано, сообщение будет скопировано в буферное пространство. Затем начинается вторая посылка. На этот момент со- ответствующая пара операций приема и посылки запущена, и обе опе- рации обязаны завершиться. Процесс с номером 1 затем вызывает свою вторую операцию приема, которая получит буферизованное со- общение. Заметим, что процесс 1 получает сообщения в порядке, об- ратном порядку их передачи. Однозначность выполнения коммуникаций в MPI должен обеспе- чить программист. Предположим, что посылка инициирована. Тогда возможно, что процесс-получатель повторно инициирует прием, соот- ветствующий этой посылке, хотя сообщение все еще не принято, по- скольку оно всякий раз обгоняется другим сообщением, посланным другим источником. Аналогично предположим, что прием был уста- новлен многопоточным процессом. Тогда возможно, что сообщения, соответствующие этому приему, принимаются повторно, хотя прием все еще не закрыт, поскольку он обгоняется другими приемами, уста- новленными на этом узле. Предупредить зависание в такой ситуации является обязанностью программиста. 60 Ограничение по ресурсам . Любое выполнение операций обмена предполагает наличие ресурсов, которые могут быть ограниченными. Может иметь место ошибка, когда недостаток ресурсов ограничивает выполнение вызова. Хорошая реализация MPI обеспечивает фиксированный объем ре- сурсов для каждой ждущей посылки в режиме готовности или син- хронном режиме и для каждого ждущего приема. Однако буферное пространство может быть израсходовано на хранение сообщений, по- сланных в стандартном режиме, или занято на хранение сообщений, посланных в буферном режиме, когда прием для соответствующей пары недоступен. В таких случаях объем пространства, доступного для буферизации, будет много меньше, чем объем памяти данных на многих системах. MPI позволяет пользователю обеспечить буферную память для со- общений, посланных в буферизованном режиме. Более того, MPI опи- сывает детализированную операционную модель для использования этого буфера. Операции буферизованной передачи, которые не могут завер- шиться из-за недостатка буферного пространства, являются ошибоч- ными. Когда такая ситуация выявлена, появляется сигнал об ошибке, и это может вызвать ненормальное окончание программы. С другой стороны, операция стандартной посылки, которая не может завер- шиться из-за недостатка буферного пространства, будет просто бло- кирована до освобождения буферного пространства или установле- ния соответствующего приема. Это поведение предпочтительно во многих ситуациях. Рассмотрим ситуацию, в которой поставщик многократно генерирует новые зна- чения и посылает их потребителю. Предположим, что генерация про- изводится быстрее, чем потребитель может принять их. Если исполь- зуются буферизованные посылки, то результатом будет перегрузка буфера. Чтобы предупредить такую ситуацию, в программу необхо- димо ввести дополнительную синхронизацию. Если используются стандартные передачи, то производитель будет автоматически следо- вать за блокированием его операций из-за недостатка буферного про- странства. В некоторых ситуациях недостаток буферного пространст- ва ведет к дедлоку. 61 Пример 3.6. Пример корректного обмена сообщениями. CALL MPI_COMM_RANK(comm, rank, ierr) IF (rank.EQ.0) THEN CALL MPI_SEND(sendbuf, count, MPI_REAL, 1, tag, comm, ierr) CALL MPI_RECV(recvbuf,count,MPI_REAL,1,tag, comm, status, ierr) ELSE CALL MPI_RECV(recvbuf,count,MPI_REAL,0,tag, comm, status, ierr) CALL MPI_SEND(sendbuf, count, MPI_REAL, 0, tag, comm, ierr) END IF Эта программа будет успешной, даже если не будет буферного пространства для данных. Операция стандартной передачи данных в этом примере может быть заменена синхронной передачей. Пример 3.7. Пример некорректного обмена сообщениями. CALL MPI_COMM_RANK(comm, rank, ierr) IF (rank.EQ.0) THEN CALL MPI_RECV(recvbuf,count,MPI_REAL,1,tag, comm, status, ierr) CALL MPI_SEND(sendbuf, count, MPI_REAL, 1, tag, comm, ierr) ELSE CALL MPI_RECV(recvbuf,count,MPI_REAL,0,tag, comm, status, ierr) CALL MPI_SEND(sendbuf, count, MPI_REAL, 0, tag, comm, ierr) END IF Операция приема первого процесса обязана завершиться перед его посылкой и может завершиться только в том случае, если выполнена соответствующая посылка второго процесса. Операция приема второ- го процесса обязана завершиться перед его посылкой и может завер- шиться только тогда, если выполнена соответствующая посылка пер- вого процесса. Эта программа будет всегда в состоянии взаимного блокирования. Пример 3.8. Пример обмена: результат зависит от буферизации. CALL MPI_COMM_RANK(comm, rank, ierr) IF (rank.EQ.0) THEN CALL MPI_SEND(sendbuf, count, MPI_REAL, 1, tag, comm, ierr) CALL MPI_RECV(recvbuf,count,MPI_REAL,1, tag, comm, status, ierr) ! rank.EQ.1 ELSE CALL MPI_SEND(sendbuf, count, MPI_REAL, 0, tag, comm, ierr) CALL MPI_RECV(recvbuf,count,MPI_REAL, 0, tag, comm, status, ierr) END IF 62 Сообщение, посланное каждым процессом, должно быть скопиро- вано перед окончанием операции посылки и до старта операции приема. Чтобы завершить программу, необходимо, чтобы по крайней мере одно из двух сообщений было буферизовано. Значит, программа может быть буферизованной, только если коммуникационная система может буферизовать, по крайней мере, count слов данных 3.6. РАСПРЕДЕЛЕНИЕ И ИСПОЛЬЗОВАНИЕ БУФЕРОВ Пользователь может описать буфера, используемые для буфериза- ции сообщений, посылаемых в режиме буферизации. Буферизация выполняется отправителем. MPI_BUFFER_ATTACH (buffer, size) IN buffer начальный адрес буфера (альтернатива) IN size размер буфера в байтах (целое) int MPI_Buffer_attach (void* buffer, int size) MPI_BUFFER_ATTACH (BUFFER, SIZE, IERROR) INTEGER SIZE, IERROR void MPI::Attach_buffer(void* buffer, int size) Предусмотренный в MPI буфер в памяти пользователя использу- ется для буферизации исходящих сообщений. Буфер используется только сообщениями, посланными в буферизованном режиме. Только один буфер может быть присоединен к процессу за один раз. MPI_BUFFER_DETACH ( buffer_addr, size) OUT buffer_addr начальный адрес буфера (альтернатива) OUT size размер буфера в байтах (целое) int MPI_Buffer_detach(void* buffer_addr, int * size) MPI_BUFFER_DETACH(BUFFER_ADDR, SIZE, IERROR) INTEGER SIZE, IERROR Int MPI :: Detach_buffer (void*& buffer) Вызов возвращает адрес и размер отключенного буфера. Операция будет блокирована, пока находящееся в буфере сообщение не будет передано. После выполнения этой функции пользователь может по- вторно использовать или перераспределять объем, занятый буфером. 63 Пример 3.9. Обращение к функциям использования буферов. #define BUFFSIZE 10000 int size char *buff; MPI_Buffer_attach( malloc(buf, BUFFSIZE); /* буфер может теперь быть использован MPI_Bsend */ MPI_Buffer_detach( &buff,&size); /* размер буфера уменьшен до нуля */ MPI_Buffer_attach( buff, size); /* буфер на 10000 байтов доступен снова */ Если никакого буфера не подключено, то MPI ведет себя, как если бы с процессом был связан буфер нулевого размера. 3.7. НЕБЛОКИРУЮЩИЙ ОБМЕН На многих системах можно улучшить характеристики путем со- вмещения во времени процессов обмена и вычислений. Механизмом, который часто приводит к лучшим характеристикам, является небло- кирующий обмен Неблокирующий вызов инициирует операцию посылки, но не за- вершает ее. Вызов начала посылки будет возвращать управление пе- ред тем, как сообщение будет послано из буфера отправителя. От- дельный вызов для завершения посылки необходим, чтобы завершить обмен, то есть убедиться, что данные уже извлечены из буфера отпра- вителя. Посылка данных из памяти отправителя может выполняться па- раллельно с вычислениями, выполняемыми на процессе-отправителе после того, как передача была инициирована до ее завершения. Ана- логично, неблокирующий вызов инициирует операцию приема, но не завершает ее. Вызов будет закончен до записи сообщения в приемный буфер. Необходим отдельный вызов завершения приема, чтобы за- вершить операцию приема и проверить, что данные получены в при- емный буфер. Посылка данных в память получателя может выпол- няться параллельно с вычислениями, производимыми после того, как прием был инициирован, и до его завершения. Использование небло- кируемого приема позволит также избежать системной буферизации и копирования память–память, когда информация появилась прежде- временно на приемном буфере. Неблокируемые вызовы начала посылки могут использовать четы- ре режима: стандартный, буферизуемый, синхронный и по готовности с сохранением их семантики. Передачи во всех режимах, исключая режим по готовности, могут стартовать вне зависимости от того, был 64 ли инициирован соответствующий прием; неблокируемая посылка по готовности может быть начата, только если инициирован соответст- вующий прием. Во всех случаях вызов начала посылки является ло- кальным: он заканчивается немедленно, безотносительно к состоянию других процессов. Если при вызове обнаруживается нехватка некото- рых системных ресурсов, тогда он не может быть выполнен и возвращает код ошибки. Вызов завершения посылки заканчивается, когда данные извлече- ны из буфера отправителя. Если режим передачи синхронный, тогда передача может завершиться, только если соответствующий прием стартовал, то есть прием инициирован и соответствует передаче. В этом случае вызов |