Коммуникаторы. 
Теория разработки параллельных программ на основе библиотеки MPI

Зачем нужны коммуникаторы?

Раскроем теперь смысл понятия коммуникатора. Сейчас обсудим только детали, касающиеся использования коммуникаторов. Более глубокое описание коммуникаторов будет дано в модуле «Управление группами и коммуникаторами MPI». Сообщение будет воспринято при вызове функции приема, если будут точно определены источник, тег и коммуникатор. Тег позволяет программе различать типы сообщений. Источник упрощает программирование. Вместо того, чтобы иметь уникальный тег для каждого сообщения, каждый процесс, отправляющий одну и ту же информацию, может использовать тот же тег. Но зачем нужен коммуникатор? Рассмотрим пример Предположим, вы передаете сообщения между вашими процессами, и, кроме того, используете ряд откуда-либо полученных библиотек, которые также порождают процессы, выполняемые на различных узлах, взаимодействующих друг с другом с помощью MPI. В этом случае вам нужно быть уверенным, что отправленные вами сообщения придут к вашим процессам и не будут смешаны с сообщениями, отправленными к процессам из библиотечных функций. Допустим, вы имеете три процесса, взаимодействующих друг с другом. Кроме того, каждый процесс вызывает библиотечную функцию, и три параллельные части библиотеки взаимодействуют друг с другом. Вам хочется иметь два различных «пространства» сообщений, один для ваших сообщений и один для библиотечных сообщений. Вам не хотелось бы получить какоелибо перемешивание этих сообщений.

Рис. 3.1 Намеченное поведение коммуникаций между процессами

Блоки на рис. 3.1 представляют собой части параллельных процессов. Время растет сверху вниз на каждой диаграмме. Цифры в круглых скобках НЕ параметры, а номера процессов. Например, send (1) означает отправку сообщения процессу 1, recv (any) означает получение сообщения от любого процесса. Пользовательский (вызывающий) код находится в белом (незатененном) блоке. Затененный блок (вызываемый) представляет собой пакет (параллельной) библиотеки, вызванной пользователем. Наконец, стрелки представляют собой перемещение сообщения от отправителя Тем кнеполучателю менее, нет. никакой гарантии, что события произойдут в нужном порядке, так как относительное расписание процессов на различных узлах может меняться от исполнения к исполнению. Предположим, вы изменили третий процесс, добавив некоторые вычисления вначале. Последовательность событий может оказаться такой, что представлена на рис. 3.2.

В этом случае коммуникации не происходят, как было намечено. Первый «receive» в процессе 0 теперь получает «send» из библиотечной функции в процессе 1, а не намеченный (и теперь задержанный) «send» из процесса 2. В результате все три процесса зависают. Проблема решается разработчиком библиотеки за счет того, что библиотека запрашивает новый и уникальный коммуникатор и определяет этот коммуникатор во всех вызовах функций отправки и получения, которые делаются библиотекой. Это создает библиотечное («вызываемое») пространство сообщений отделенное от пользовательского («вызывающего») пространства сообщений. Можно ли было использовать теги, чтобы осуществить разделение пространства сообщений? Проблема с тегами состоит в том, что их значения задаются программистом, а он может использовать тот же тег, что и параллельная библиотека, использующая MPI. С коммуникаторами система, а не программист, осуществляет идентификацию — система назначает коммуникатор пользователю и он назначает отличный 20 коммуникатор библиотеке — так что возможность перекрытия не возникает.

Группы коммуникаторов и процессов В дополнение к работе с параллельными библиотеками, коммуникаторы полезны также в организации коммуникаций внутри приложения. Мы описали коммуникатор, который включает все процессы в приложении. Но программист может также определить подмножество процессов, называемое группой процессов, и прикрепить один или больше коммуникаторов к этой группе процессов. Коммуникатор определяет, что коммуникация будет теперь ограничиваться этими процессами. В следующем ниже примере коммуникационным шаблоном является 2-мерная решетка (2D-mesh). Схема коммуникаций по двумерной решетке используется, например, для задач с геометрической структурой, в которой значения в соседних точках необходимы для уточнения значения в точке. Лучшим способом распараллеливания этой задачи является блочная декомпозиция данных по двум размерностям, и, затем, отображение блоков на 2- мерной решетке процессов. Решеточная топология — это абстракция, указывающая, каким процессам принадлежат соседние данные. Для точек внутри каждого процессного блока вся необходимая информация для уточнения точки содержится в этом процессе. Чтобы уточнить граничные точки процесса, необходимо знать строки и столбцы точек, содержащихся у соседей. Пусть, например, каждый из шести блоков представляет собой процесс. Каждый процесс должен обмениваться данными с соседями сверху и снизу, справа и слева. Кодировать эту коммуникацию будет проще, если процессы сгруппировать по столбцам (для коммуникаций выше/ниже) и строкам (для коммуникаций направо/налево). Итак, каждый процесс принадлежит трем коммуникаторам, что указано словами в блоке этого процесса: один коммуникатор на все процессы (мировой 21 коммуникатор, который дан по умолчанию), один коммуникатор на его строку и один коммуникатор на его столбец. Эти коммуникаторы указаны ниже рис 3.3.

Рис. 3.3 Коммуникаторы

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