Одним из преимуществ использования MPI-интерфейса перед традиционными UNIX/Linux-процессами и сокетами является способность MPI-среды запускать одновременно несколько выполняемых файлов. MPI-реализация может запустить несколько выполняемых файлов, установить между ними базовые отношения и идентифицировать каждый выполняемый файл. В этой книге мы используем MPICH-реализацию MPI-интерфейса 1. При выполнении команды $ mpirun -np 16 /tmp/mpi_example1 будет запущено 16 процессов. Каждый процесс будет выполнять программу с именем mpi_example1. Все процессы могут использовать разные доступные процессоры. Кроме того, каждый процесс может выполняться на отдельном компьютере, если MPI работает в среде кластерного типа. Процессы при этом будут выполняться параллельно. Команда mpirun представляет собой основной сценарий, который отвечает за запуск MPI-заданий на необходимом количестве процессоров. Этот сценарий изолирует пользователя от подробностей запуска параллельных процессов на различных компьютерах. Здесь будет запущено 16 копий программы mpi_examplel. Несмотря на то что стандарт MPI-2 определяет функции порождения, которые можно использовать для динамического добавления программ к выполняемому MPI-приложению, этот метод не популярен. В общем случае необходимое количество процессов создается при запуске MPI-приложения. Следовательно, во время старта этот код тиражируется N раз. Описаннал схема легко поддерживает модель параллелизма SPMD (SIMD), поскольку одна и та же программа запускается одновременно на нескольких процессорах. Данные, с которыми каждой программе нужно работать, определяются после запуска программ. Этот метод старта одной и той же программы на нескольких процессорах можно развить, если нужно реализовать модель MPMD. Вся работа MPI-программы делится между несколькими процессами, запускаемыми на старте программы. Информация о распределении «обязанностей» (т.е. кто что делает и какие процессы работают с какими данными) содержится в самой выполняемой программе. Компьютеры, задействованные в этой работе, перечис л яются в файле machines.arch (machines.Linux в данно м случае) с использование м и м ени ко м пьютера. Местоположение это г о файла зависит от конкретной реализации. В зависи м ости от инсталляции, взаи м одействие ко м пьютеров, перечисленных в это м файле, будет обеспечено либо ко м андой ssh, либо UNIX/Linux-ко м андой ' r'.

 

Дифференциация задач по рангу

Во время старта процессов, включенных в MPI-приложение, МРI-среда назначает каждому процессу ранг и группу коммуникации. Ранг хранится как int-значение и служит в качестве идентификатора процесса для каждой MPI-задачи. Группа коммуникации определяет, какие процессы можно включить во взаимодействие типа «точка-точка». Сначала все MPI-процессы относят к группе, действующей по умолчанию. Заменить членов группы коммуникации можно, запустив приложения. После старта каждого процесса необходимо определить его ранг с помощью функции MPI_Comm_rank (). Функция MPI_Comm_rank () возвращает ранг вызывающего процесса. В первом аргументе, передаваемом функции, вызывающий процесс определяет, с каким коммуникатором он связывается, а его ранг возвращается во втором аргументе. Пример использования функции MPI_Comm_rank () показан в листинге 9.1.

// Листинг 9.1. Использование функции MPI_Comm_rank() //.. .

int Tag = 33;

int WorldSize;

int TaskRank;

MPI_Status Status;

MPI_Init (&argc, &argv) ;

MPI_Comm_rank(MPI_COMM_WORLD, &TaskRank) ; MPI_Comm_size(MPI_COMM_WORLD, &WorldSize) ; //.. .

Коммуникатору MPI_COMM_WORLD по умолчанию при запуске назначаются все MPI-задачи. MPI-задачи группируются по коммуникаторам, которые определяют группу коммуникации. В листинге 9.1 ранг возвращается в переменной TaskRank. Каждый процесс должен иметь уникальный ранг. После определения ранга задаче передаются соответствующие данные либо определяется код, который ей надлежит выполнить. Рассмотрим следующие варианты.

Вариант 1. Простая MPMD-модель   Вариант 2. Простая SIMD-модель

if(TaskRank == 1){   if(TaskRank == 1){

// Некоторые действия.   // Используем одни данные.

}   }

if (TaskRank == 2){   if(TaskRank == 2){

// Другие действия.   // Используем другие данные.

}   }

В первом варианте ранг используется для разграничения между процессами выполняемой работы, а во втором — для разграничения данных, которые они должны обрабатывать. Несмотря на то что каждый выполняемый MPI-файл стартует с одним и тем же кодом, модель MPMD (MIMD) можно реализовать с помощью рангов и соответствующего ветвления программы. Аналогично после определения ранга данным процесса можно назначить некоторый тип, тем самым определив конкрет-ные данные, с которыми должен работать конкретный процесс. Ранг также используется при передаче сообщений. MPI-задачи идентифицируют одна другую при обмене сообщениями по рангам и ко мм уникатора м. Функции MPI_Send () | MPI_Recv() используют ранг в качестве указания пунктов назначения и отправления соответственно. При выполнении вызова

MPI_Send(Buffer,Count, MPI_LONG, TaskRank, Tag,Comm) ;

будет отправлено Count значений типа long MPI-процессу с рангом, равным значению TaskRank. Параметр Buffer представляет собой указатель на данные, посылаемые процессу TaskRank. Параметр Count характеризует количество элементов в буфере Buffer, а не его раз м ер. Каждое сообщение имеет тег. Этот тег позволяет отличить одно сообщение от другого, сгруппировать сообщения в классы, связать определенные сообщения с определенными коммуникаторами и пр. Тег имеет тип int, а его значение определяется пользователем. Параметр Comm представляет коммуникатор, которому назначается процесс. Если ранг и коммуникатор задачи известны, этой задаче можно посылать сообщения. При выполнении вызова

MPI_Recv(Buffer, Count, MPI_INT, TaskRank, Tag, Comm, &Status);

будет получено Count значений типа int от процесса с рангом TaskRank. Инициатор вызова будет заблокирован до тех пор, пока не получит сообщение от процесса с рангом TaskRank и соответствующим значением тега (Tag). MPI-интерфейс для параметров ранга и тега поддерживает групповые символы. Такими групповыми символами являются значения MPI_ANY_TAG и MPI_ANY_SOURCE. При использовании этих значений вызывающий процесс примет следующее полученное им сообщение независимо от его источника и тега. Параметр Status имеет тип MPI_Status. Информацию об операции приема можно получить из объекта Status. Параметр статуса содержит три поля: MPI_SOURCE, MPI_TAG и MPI_ERROR. Следовательно, объект Status можно использовать для определения тега и источника процесса-отправителя. При известном количестве процессов-участников можно точно определить отправителей сообщений и их получателей. Обычно для этого используется конкретное приложение. Распределение работы также зависит от приложения. Перед началом работы каждый процесс сразу же определяет, сколько других процессов включено в приложение. Это реализуется следующим вызовом: MPI_Comm_size(MFI_COMM_WORLD, &WorldSize) ;

С помощью этой функции определяется размер группы процессов, связанных с конкретным коммуникатором. В данном используется стандартный коммуникатор (MPI_COMM_WORLD). Количество процессов-участников возвращается в параметре WorldSize. Этот параметр имеет тип int. Если каждому процессу известно значение WorldSize, значит, он знает, сколько процессов связано его коммуникатором.

 

Группирование задач по коммуникаторам

Процессы связываются не только с ранга м и, но и с ко мм уникатора м и. Коммуникатор определяет область коммуникации для некоторого множества процессов. Все процессы, связанные с одним и тем же коммуникатором, относятся к одной и той же группе коммуникации. Работу, выполняемую MPI-программой, можно разделить между группами коммуникаций. По умолчанию все процессы относятся к группе MPI_C0MM_WORLD. Для создания новых ко м муникаторов можно использовать функцию MPI_Comm_create (). Список функций (с краткими описаниями), используемых для работы с коммуникаторами, приведен в табл. 9.1.

Благодаря использованию рангов и коммуникаторов MPI-задачи легко идентифицировать и различать. Ранг и коммуникатор позволяют структурировать программу как SPMD- или MPMD-модель либо как некоторую их комбинацию. Для упрощения кода MPI-программы мы используем ранг и коммуникатор в сочетании с параметризованным программированием и объектно-ориентированными методами. Шаблоны можно использовать не только при м енительно к аспекту различных данных SIMD-модели, но и к заданию различных типов данных. Это значительно упрощает структуру многих приложений, требующих выполнения большого объема одинаковых вычислений, но с различными типами данных. Для реализации модели MPMD (MIMD) мы рекоменлуем использовать динамический полиморфизм (поддерживаемый объектами), параметрический полиморфизм (поддерживаемый шаблонами), объекты-функции и предикаты. Для разделения всего объема работы MPI-приложения эти методы используются в сочетании с рангами и коммуникаторами MPI-процессов. При использовании объектно-ориентированного подхода работа программы делится между семействами объектов. Все семейства объектов связываются с различными коммуникаторами. Соответствие семейств объектов различным коммуникаторам способствует модульности проекта MPI-приложения. Такой способ разделения также помогает понять, как следует применить параллелизм. Мы убедились, что объектно-ориентированный подход делает MPl-программы более открытыми для расширения, атакже простыми для поддержки, отладки и тестирования.

|Таблица 9.1. Функции, используемыедля работы с коммуникаторами

 

Анатомия MPI-задачи

На рис.9.1 представлена каркасная MPI-программа. Задачи, выполняемые этой программой, просто сообщают свои ранги MPI-задаче с нулевым рангом. Каждая MPI-программа должна иметь по крайней мере функции MPI_Init() и MPI_Finalize(). Функция MPI_Init() инициализирует MPI-среду для вызывающей задачи, а функция MPI_Finalize () освобождает ресурсы этой MPI-задачи. Каждая MPI-задача должна вызвать функцию MPI_Finalize() до своего завершения. Обратите вни м ание на обращения к функция м MPI_COMM_rank () HMPI_COMM_Size (). Они используются для получения значений ранга и количества процессов, которые принадлежат MPI-приложению. Эти функции вызываются большинством MPI-приложений. Вызов же остальных MPI-функций зависит от конкретного приложения. MPI-среда поддерживает более 300 функций (подробная информация представлена в соответствующей документации).

 

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

template T multiplies(T X, T Y) {

return( X * Y);

}

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

//. . .

multiplies(3.2,4.5);

multiplies(7, 2) ; multiplies(«7/2»,«3/4»); //.. .

Здесь параметр T за м еняется типо м double, int и rational соответственно, определяя тем самым точную реализацию операции умножения. Умножение д ля разных типов данных опре д еляется по-разно м у. Это означает, что д ля разных типов данных выполняется различный код. Шаблоннал функция позволяет написать одну операцию у м ножения (в виде функции multiplies ()) и при м енить ее ко м ноги м различны м типа м данных.

 

Реализация шаблонов и модельБРМО (типы данных)

Пара м етризованные функции м ожно использовать с MPI-интерфейсо м д ля обработки ситуаций, в которых все процессы выполняют одинаковый код, но работают с различны м и типа м и данных. Так, определив значение TaskRank процесса, м ы м о-жем распознать, с каки м и данны м и и данны м и какого типа должен работать процесс. В листинге 9.2 показано, как реализовать различные задачи д ля различных рангов.

//Листинг 9.2. Использование шаблонных функций для //   определения «фронта работ» МР1-задач

int main(int argc, char *argv[]) {

//.. .

int Tag = 2; int WorldSize; int TaskRank; MPI_Status Status; MPI_Init(&argc,&argv) ,-

MPI_Comm_rank (MPI_COMM_WORLD, &TaskRank) ; MPI_Comm_size (MPI_COMM_WORLD, &WorldSize) ; //.. .

switch(TaskRank) {

case 1: multiplies(3.2,4.6); break;

case 2: multiplies(X,Y)

break; //case n:

//.. .

}

}

Поскольку не существует двух задач с одинаковым ранго м, все ветви в инструкции case листинга 9.2 будут выполнены различны м и MPI-задача м и. Кро м е того, такой тип параметризации м ожно распространить на контейнерные аргу м енты шаблонных функций. Это позволит передавать одной и той же шаблонной функции различные контейнеры объектов, содержащие различные типы объектов. Напри м ер, в листинге 9.3 показана обоб щ енная шаблоннал функция search ().

// Листинг 9.3. Использование контейнерных шаблонов в //   качестве аргументов шаблонных функций

template bool search(T Key, graph) {

//. . -

locate(Key) //. . .

}

// . . .

MPI_Comm_rank(MPI_COMM_WORLD, &TaskRank); // . . .

switch(TaskRank) {

case 1: {

graph bullion;

search search(«gold», bullion);

}

break; case 2: {

graph Coordinates; search((X,Y),Coordinates);

}

break;

//. . .

В листин г е 9.3 процесс, у которого TaskRank = 1, выполняет поиск в графе (graph) сименем bullion, содержа щ е м string<^beKTbi, а процесс, у которого TaskRank = 2, выполняет поиск в графе Coordinates, содержа щ е м ко м плексные числа. Мы не должны из м енять функцию search (), чтобы приспособиться к други м дан н ы м или типам данных, да и MPI-програм м а в это м случае и м еет более простую структуру, поскольку м ы м оже м м ногократно использовать шаблонную функцию поиска (search) для прос м отра контейнера graph, содержа щ его данные любого типа. Использование шаблонов значительно упро щ ает 5РМГ>програ мм ирование. Че м более об щ ей м ы делае м MPI-задачу, те м более гибкой она становится. Кро м е того, если некоторый шаблон прошел этап отладки и тестирования, надежность всех построенных на его основе МР1-задач м ожно считать довольно высокой, поскольку все они выполняют одинаковый код.

 

Использование полиморфизмадля реализации MPMD-модели

Полиморфиз м— одна из основных характеристик объектно-ориентированного програ мм ирования. Если язык претенлует на поддержку объектно-ориентированно г о програ мм ирования, он должен по д держивать инкапсуляцию, нас л едование и по л и м орфиз м. По л и м орфиз м — это способность объекта прини м ать м ножество форм. По л иморфизм по д держивает понятие «один интерфейс — множество реализаций • Пользователь использует одно имя, или интерфейс, реализованный различными способами и различными объекта м и. Чтобы проиллюстрировать концепцию поли м орфизма, рассмотри м класс vehicle, его пото м ков и простую функцию travel (), которая использует класс vehicle. На рис. 9.2 показана простая иерархия нашего се м ейства класса vehicle.

Самолеты, вертолеты, автомобили и подводные лодки — все это потомки класса vehicle (транспортные средства). Объект класса vehicle может заводить мотор, перемещаться вперед, поворачивать вправо, поворачивать влево, останавливаться и пр. В листинге 9.4 демонстрируется, как функция travel () использует объект класca vehicle для совершения компьютеризованного путешестви я.

// Листинг 9.4.

//Функция travel(), которая в качестве параметра использует объект класса vehicle

void travel(vehicle *Transport) {

Transport->startEngine(); Transport->moveForward() ; Transport->turnLeft();

//.. .

Transport-> stop();

}

int main(int argc, char *argv[J) {

//.. . car *Car;

Transportation = new Vechicle(); travel(Car); //.. .

}

Функция travel () принимает указатель на объект класса vehicle и вызывает методы объекта класса vehicle. Обратите внимание на то, что функция main() в листинге 9.4 объявляет объект типа саг, а не vehicle, а также на то, что функции travel () вместо объекта типа vehicle передается объект типа car. Это возможно благодаря тому, что в С++ указатель на класс может ссылаться на объект этого типа или на любой объект, который является потомком этого типа. Поскольку класс саг является производным от класса vehicle, то указатель на тип vehicle может ссылаться на объект типа саг. Функция travel () написана без учета того, какими конкретно типами vehicle- объектов она будет манипулировать. Для функции travel () вполне достаточно, чтобы ее vehicle -объекты могли запускать мотор, двигаться вперед, поворачивать влево, вправо и т.д. Если vehicle -объект способен выполнять эти действия, то функция travel () сможет справиться со своей работой. Обратите внимание на то, что на рис. 9.2 методы класса vehicle объявлены как виртуальные (virtual). Объявление методов виртуальными в базовом классе является необходимым условием динамического полиморфизма. В каждом из классов car, helicopter, submarine и airplane будут определены следующие функции.

startEngine(); moveForward(); turnLeft(); turnRight(); stop(); //.. .

При этом объявление каждой функции будет соответствовать типу транспортного средства. Несмотря на то что транспортное средство каждого типа способно двигаться вперед, метод, в котором обеспечивается движение автомобиля, отличается от метода перемещения подводной лодки. Управление поворотом вправо у самолета отличается от управления таким же поворотом у автомобиля. Следовательно, транспорт-ное средство каждого типа должно реализовать необходимые операции для получения законченного описания «своего» класса. Поскольку эти операции объявляются как виртуальные в базовом классе, они и являются кандидатами для реализации полиморфизма. Если vehicle -указатель, переданный функции travel (), в действительности ссылается на объект типа car, то методами, вызываемыми в этой функции (startEngine (), moveForward() и пр.), реально окажутся те, которые определены в классе car. Если vehicle -указатель, переданный функции travel (), вдействительности ссылается на объект класса airplane, то методами, вызываемыми в этой функции, реально окажутся те, которые определены в классе airplane. Это и есть тот случай, когда много форм реализуется при одном интерфейсе. Несмотря на то что функция travel () вызывает только один набор методов, поведе н ие этих м етодов может радикаль н о отличаться в зависи м ости от то г о, указатель на объект како г о vehicle -класса был назначен vehicle -указателю. По л и м орфиз м фу н кции travel () состоит в то м, что при каждо м вызове о н а м ожет выпо лн ять соверше нн о раз н ые действия. И в самом де л е, поско л ьку фу н кция travel () испо л ьзует указате л ь на к л асс vehicle, в булу щ ем ее можно испо л ьзовать д л я типов, производных от к л асса vehicle, которые бы л и неизвестны и л и не су щ ествовали во время разработки функции travel(). До тех пор пока буду щ ие vehicle -к л ассы будут нас л едовать к л асс vehicle и опреде л ять необходимые методы, ими можно будет управ л ять с помо щ ью фу н кции travel (). Этот тип по л иморфизма называется динамическим (runtime polymorphism), поско л ьку фу н кция travel () н е знает точно, какие и м енно функции startEngine (), moveForward( ) и л и turnLeft () она будет вызывать, до тех пор, пока про г ра мм а не начнет выпо л няться.

Этот тип полиморфиз м а полезен при реализации MPI-програ мм, которые используют модель MPMD. Если MPI-задачи работают с указател ям и на базовые классы, то полиморфиз м позволяет MPI-классу также работать с любы м и класса м и, производными от не г о. Предположи м, что в м есто объявления с указателе м функция travel () (см. листин г 9.4) имела бы такое объявление: void travel(vehicle Transport);

В этом случае при обра щ ении к функциям startEngine (), moveForward () и прочим вызывались бы м етоды, принадлежа щ ие только классу vehicle, и обращение к производным классам было пробле м атичны м. Использование же указателя на класс vehicle и объявления м етодов в классе vehicle виртуальны м и (virtual) заставляют работать м еханиз м поли м орфиз м а. MPI-задачи, которые м анипулируют указателями на базовые классы, мо г ут точно так же использовать преиму щ ества полиморфизма, как функции travel () удается работать с любым типом vehicle-объекта (настоя щ и м или булу щ им). Этот метод открывает большие перспективы дл я булу щ е г о кластерных приложений, а также приложений SMP (Symmetrical Multiprocessing — симметричнал мно г опроцессорнал обработка) и MPP (Massively Parallel Processing — массовал параллельнал обработка), в которых необходимо реализовать модели MPMD. Чтобы понять, как модель MPMD работает в MPI-контексте, попробуем использовать нашу функцию travel () в качестве МРТзадачи, которая является частью подсистемы поиска. Все MPI-задачи отвечают за выполнение поисково-спасательных операций применительно к vehicle-объектам различного типа. Очевидно, что каждое транспортное средство (vehicle-объект) характеризуется рааличными способами движения. Несмотря на то что проблема, стоя щ ал перед всеми MPI-задачами, заключается в выполнении поиска, все они будут иметь различные коды, поскольку все эти задачи используют различные виды vehicle-объектов, которые работают по-разно м у и требуют различных данных. Код, который содержится в листинге 9.5, необходимо запустить в нашей среде MPICH с по м о щ ью слелую щ ей ко м анды.

$ mpirun -np 16 /trap/search_n_rescue

// Листинг 9.5. Реализация MPI-задачами простого

// поиска и имитации спасения поврежденных

// объектов

template bool travel(vehicle *Transport,

set Location, T Object)

{

//.. .

Transport->startEngine(); Transport->moveForward(XDegrees); Transport->turnLeft(YDegrees); //.. .

if (Location.find(Transport->location() == Object){ // . .. rescue()

}

//.. .

}

int main(int argc, char *argv[])

326 Глава 9. Реализация моделей SPMD и MPMD с помощью шаблонов..

{

//...

int Tag = 2; int WorldSize; int TaskRank; MPI_Status Status; MPI_Init(&argc,&argv);

MPI_Comm_rank(MPI_COMM_WORLD, &TaskRank); MPI_Comm_size(MPI_COMM_WORLD, &WorldSize); //. . .

switch(TaskRank) {

case 1: {

//. . .

car * Car;

set SearchSpace

travel(Car, SearchSpace,Street); //.. .

}

break;

case 2:

{

//.. .

helicopter *BlueThunder; set NationalAirSpace; travel(BlueThunder,

NationalAirSpace,

AirSpace);

//.. .

}

//case n: //. . .

}

}

Программа search_n_rescue будет запущена в 16 процессах, причем все процессы потенциально могут выполняться на различных процессорах, а все процессоры — находиться на различных компьютерах. Несмотря на то что все процессы выполняют один и тот же код, их действия могут радикально различаться (как и данные, с которыми они работают). Шаблоны и полиморфизм позволяют отличать одну MPI-задалу от другой (а значит, и данные, которые они будут использовать). Обратите внимание на то, что в листи н ге 9.5 МРI - процесс, у которого TaskRank = 1, будет использовать объект класca Car и контейнер, содержа щ ий streets - объекты . MPI-процесс, у которо г о TaskRank = 2, будет использовать объект класса helicopter и аir_spасе объекты. Обе задачи вызывают шаблонную функцию travel (). Поскольку шаблоннал функция travel () манилулирует указателями на класс vehicle, она может воспользоваться преимущест-вами полиморфизма и выполнять операции с потомками класса vehicle. Это означает, что, хотя все MPI-задачи вызывают одну и гу же функцию travel (), действия, вы полняемые этой функцией, рааличны. Обратите внимание на то, что в функции travel () нет инструкций case или if, которые бы пытались идентифицировать тип vehicle -объекта, с которым она работает. Конкретный vehicle -объект определяется типом, на который используется указатель. Это MPI-приложение может работать потенциально с 16 различными транспортными средствами, каждое из которых характеризуется собственным типом мобильности и областью поиска. Существуют и другие методы, которые можно использовать для реализации модели MPMD в среде MPI, но полиморфический подход обычно требует меньшего объема кода.

Основные два типа полиморфизма, которые мы здесь демонстрируем, — это полиморфизм динамического связывания, по д держиваемый наследованием и виртуальными методами, и параметрический полиморфизм, по д держиваемый шаблонами. Функция travel () в листин г е 9.5 использует оба типа полиморфизма. Полиморфизм, основанный на наследовании, характеризует параметр vehicle *Transport, а параметрический полиморфизм — параметры set и T Object. Параметрический полиморфизм представляет собой механизм, благодаря которому один и тот же код используется для различных типов, передаваемых в качестве параметров. Различные типы полиморфизма, которые позволяют упростить МРТзадачи и сократить код, необходимый для реализации MPI-программы, перечислены в табл. 9.2.

Таблица 9.2. Различные типы полиморфизма, которые можно использовать  для упрощения МРI-задач

 

Введение MPMD-модели c помощью функций -объектов

Функции-объекты используются в стандартных алгоритмах для реализации горизонтального полиморфизма. Полиморфизм, реализованный с помощью передачи параметра vehicle *Transport в листинге 9.5, является вертикальным, поскольку для функционирования необходимо, чтобы классы были связаны наследованием. При горизонтальном полиморфизме классы связаны не наследованием, а интерфейсом. Все функции-объекты определяют операторную функцию operator (). Функции-объекты позволяют разрабатывать MPI-задачи с использованием некоторой общей формы.

// Функция-объект class some_class{ //.. .

operator(); //

};

template T mpiTask(T X) {

//

Т Result; Result = X() //. . .

}

Шаблонная функция mpiTask () будет работать с любым типом T, который имеет соответствующим образом определенную функцию operator ().

//. . .

MPI_Init(&argc, &argv);

MPI_Comm_rank(MPI_COMM_WORLD, &TaskRank); MPI_Comm_size(MPI_COMM_WORLD, &WorldSize); //. . .

if(TaskRank == 0){ //. . .

user_defined_type M; mpiTask(M); //.. .

}

if(TaskRank == N){ //.. .

some_other_userdefined_type N; mpiTask (N) ;

}

//----

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

 

Помимо упрощения и сокращения размеров кода МРТзадачи с помощью полиморфизма и шаблонов, мы можем также упростить взаимодействие между MPI-задачами, воспользовавшись преимуществами перегрузки операторов. Функции MPI_Send () и MPI_Recv () имеют следующий формат:

MPI_Send(Buffer, Count, MPI_LONG, TaskRank, Tag, Comm);

MPI_Recv(Buffer,Count,MPI_INT, TaskRank, Tag, Comm, &Status);

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

Таблица 9.3 Прототипы MPI-функций отправки и приема данных

Функции Описание

#include «mpi.h»

int MPI_Send (void *Buffer,int Count, MPI_Datatype Туре, int Destination, int MessageTag, MPI_Comm Comm) ; Выполняет базовую отправку данных

int MPI_Send_init (void *Buffer,int Count, MPI_Datatype Type, int Destination, int MessageTag, MPI_Comm Comm, MPI_Request *Request); Инициализирует дескриптор для стандартной отправки данных

int MPI_Ssend (void *Buffer,int Count, MPI_Datatype Type, int Destination, int MessageTag, MPI_Comm Comm); Выполняет базовую отправку данных с синхронизацией

int MPI_Ssend_init (void *Buffer,int Count, MPI_Datatype Type, int Destination, int MessageTag, MPI_Comm Comm, MPI_Request *Request); Инициализирует дескриптор для стандартной отправки данных с синхронизацией

int MPI_Rsend (void *Buffer,int Count, MPI_Datatype Type, int Destination, int MessageTag, MPI_Comm Comm) ; Выполняет базовую отправкуданных с сигналом готовности

int MPI_Rsend_init (void *Buffer,int Count, MPI_Datatype Type, int Destination, int MessageTag, MPI_Comm Comm, MPI_Request *Request); Инициализирует дескриптор для стандартной отправки данных с сигналом готовности

int MPI_Isend (void *Buffer,int Count, MPI_Datatype Type, int Destination, int MessageTag, MPI_Comm Comm, MPI_Request *Request ); Запускает отправку без блокировки

int MPI_Issend (void *Buffer,int Count, MPI_Datatype Туре, int Destination, int MessageTag, MPI_Comm Comm, MPI_Request *Request); Запускает синхронную отправку без блокировки

int MPI_Irsend (void *Buffer,int Count, MPI_Datatype Туре, int Destination, int MessageTag, MPI_Comm Comm, MPI_Request *Request); Запускает неблокирующую отправкуданных с сигналом готовности

int MPI_Recv (void *Buffer,int Count, MPI__Datatype Type, int source, int MessageTag, MPI_Comm Comm, MPI_Status *Status); Выполняет базовый прием данных

int MPI_Recv_init (void *Buffer,int Count, MPI_Datatype Type, int source, int MessageTag, MPI_Comm Comm, MPI_Request *Request); Инициализирует дескриптор для приема данных

int MPI_Irecv (void *Buffer,int Count, MPI_Datatype Type, int source, int MessageTag, MPI_Comm Comm, MPI_Request *Request); Запускает прием данных без блокировки

int MPI_Sendrecv (void *sendBuffer, int SendCount, MPI_Datatype SendType, int Destination, int SendTag, void *recvBuffer, int RecvCount, MPI_Datatype RecvYype, int Source, int RecvTag, MPI_Comm Comm, MPI_Status *Status); Отправляет и принимает сообщение

int MPI_Sendrecv_replace (void *Buffer,int Count, MPI_Datatype Туре, int Destination, int SendTag,int Source,int RecvTag, MPI_Comm Comm, MPI_Status *Status); Отправляет и принимает сообщение с использованием единого буфера

Наша цель — обеспечить отправку и получение MPI-данных с помо щ ью потоково г о представления iostream-классов. Данные удобно отправлять, используя следую щ ий синтаксис.

//...

int X; float Y;

user_defined_type Z;

cout « X << Y « Z;

//...

Здесь разработчик не должен указывать типы данных при вставке их в объект cout. Для вывода этих данных трех типов достаточно определить оператор "<<". Анало г ично можно поступить при выделении данных из потоково г о объекта cin.

//...

int X; float Y;

user_defined_type Z;

cin >> X >> Y >> Z;

//...

В инструкции ввода данных их типы не задаются. Перегрузка операторов позволяет разработчику использовать этот метод для MPI-задач. Поток cout реализуется из класса ostream, а поток cin — из класса istream. В этих классах определены операторы "<<" и ">>" для встроенных С++-типов данных. Например, класс ostream содержит ряд перегруженных операторных функций "<<".

//.. .

ostream& operator<<(char с);

ostream& operator<<(unsigned char с);

ostream& operator<<(signed char с);

ostream& operator<<(const char *s);

ostream& operator<<(const unsigned char *s);

ostream& operator<<(const signed char *s);

ostream& operator<<(const void *p);

ostream& operator<<(int n);

ostream& operator<<(unsigned int n);

ostream& operator<<(long n);

ostream& operator<<(unsigned long n);

//.. .

С помощью этих определений пользователь классов ostream и istream применяет объекты cout и cin, не указывал типы передаваемых данных. Этот метод перегрузки можно использовать для упрощения МРI- взаимодействия. Мы рассмотрели идею PVM-потока в главе 6. Здесь мы применяем тот же подход к созданию MPI-потока, используя структуру классов istream и ostream в качестве руководства для разработки класса mpi_stream. Потоковые классы состоят из компонентов состояния, буфера и преобразования. Компонент состояния представлен классом ios; компонент буфера — классами streambuf, stringbuf или filebuf. Компонент преобразования обслуживается классами istream, ostream, istringstream, ostringstream, ifstream и ofstream. Компонент состояния отвечает за инкапсуляцию состояния потока. Класс ios включает формат потока, информацию о состоянии (работоспособное или состояние отказа), факт достижения конца файла (eof). Компонент буфера используется для хранения считываемых или записываемых данных. Классы преобразования предназначены для перевода данных встроенных типов в потоки байтов и обратно. UML-диаграмма семейства классов iostream показана на рис. 9.3.

 

Перегрузка операторов «<<» и «>>» для организации взаимодействия между MPI-задачами

Взаимоотношения и функциональность классов, показанных на рис. 9.3, можно использовать как своего рода образец для проектирования класса mpi_streams. И хотя проектирование потоковых MPI-классов требует больше предварительной работы по сравнению с непосредственны м использование м функций MPI_Recv () HMPI_Send() , в целом оно делает MPI-разработку значительно проще. А если программы с параллельной обработкой можно упростить, это нужно сделать обязательно. Уменьшение сложности программ — весьма достойнал цель для программиста. Здесь мы представляем лишь каркас класса mpi_stream. Но этого вполне достаточно для получения понятия о конструкции потокового MPI-класса. После разработки класса mpi_stream можно приступать к упрощению организации взаимодействия между MPI-задачами в большинстве MPI-программ. Листинг 9.6 содержит фрагмент из объявления класса mpi_stream.

// Листинг 9.6. Фрагмент объявления

// класса mpi_stream

class mpios{ protected:

int Rank;

int Tag;

MPI_Comm Comm;

MPI_Status Status;

int BufferCount;

//.- . public:

int tag(void);

//...

}

class mpi_stream public mpios{ protected:

mpi_buffer Buffer;

//.. .

public: //.. .

mpi_stream(void) ;

mpi_stream(int R,int T,MPI_Comm С);

void rank(int R);

void tag(int T);

void comm(MPI_Comm С);

mpi_stream &operator<<(int X);

mpi_stream &operator<<(float X);

mpi_stream &operator<<(string X);

mpi_stream &operator<<(vector &X);

mpi_stream &operator<<(vector &X),

mpi_stream &operator<<(vector &X);

mpi_stream &operator<<(vector &X);

mpi_stream &operator>>(int &X);

mpi_stream &operator>>(float &X);

mpi_stream &operator>>(string &X);

mpi_stream &operator>>(vector &X);

mpi_stream &operator>>(vector &X);

mpi_stream &operator>>(vector &X);

mpi_stream &operator>>(vector &X);

//. . .

};

Для того чтобы сократить описание, мы объединили классы impi _stream и ompi _stream в единый класс mpi _stream. И точно так же, как классы istream и ostream перегружают операторы "<<" и ">>", мы обеспечим их перегрузку в классе mpi_stream. В листинге 9.7 показано, как можно определить эти перегруженные операторы:

// Листинг 9.7. Определение операторов   и **»*

//. . .

mpi_stream &operator<<(string X) {

MPI_Send(const_cast(X.data()),X.size(),

MPI__CHAR, Rank, Tag, Comm) ; return(*this);

}

// Упрощенное управление буфером, mpi_stream &operator<<(vector &X) {

long *Buffer;

Buffer = new long[X.size()]; copy(X.begin(),X.end(),Buffer);

MPI_Send(Buffer,X.size(),MPI_LONG,Rank,Tag,Comm); delete Buffer; return(*this);

}

// Упрощенное управление буфером, mpi_stream &operator>>(string &X) {

char Buffer[10000];

MPI_Recv(Buffer,10000,MPI_CHAR,Rank,Tag,Comm, &Status); MPI_Get_count(&Status,MPI_CHAR,&BufferCount); X.append(Buffer); return(*this);

}

Назначение класса mpios в листинге 9.7 такое же, как у класса ios в семействе классов iostream, а именно: поддерживать состояние класса mpi_stream. Все типы данных, которые должны использоваться в ваших MPI-приложениях, должны иметь операторы "<<" и ">>", перегруженные с учетом каждого типа данных. Здесь мы продемонстрируем несколько простых перегруженных операторов. В каждом случае мы представляем упро щ енный вариант управления буфером. На практике необходимо прелусмотреть обработку исключений (на базе шаблонных классов) и распределение памяти (на базе классов-распределителей ресурсов). В листинге 9.7 обратите внимание на то, что класс mpios содержит коммуникатор, статус класса mpi_stream, номер буфера и значение ранга или тега (это — лишь одна из возможных конфигураций класса mpi_stream— существует множество других). После того как класс mpi_stream определен, его можно использовать в любой MPI-программе. Взаимодействие между MPI-задачами может быть организовано следую щ им образом.

//. . .

int X; float Y;

vector Z;

mpi_s tream S tream (Rank, Tag, MPI_WORLD_COMM) ;

Stream « X << Z; Stream << Y;

//...

Stream >> Z;

Такой подход позволяет программисту, поддерживал потоковое пре д ставление, упростить МРТко д. Безусловно, в опре д еление операторов "<<" и ">>" необходимо включить соответствующую проверку ошибок и обработку исключительных ситуаций.