Камерон Хьюз - Параллельное и распределенное программирование на С++

Главное внимание необходимо уделить сетевому доступу пользователя, запускаю щ его PVM-программу. Владелец PVM-программы должен иметь доступ к каждому компьютеру, включенному в пул процессоров. Этот доступ будет использовать либо команду rsh, либо rlogin, либо ssh. Выполняемая программа должна быть доступна на каждом компьютере, а PVM-среда должна быть «в курсе» того, какие компьютеры имеются в наличии и где будут инсталлированы выполняемые файлы.

# Строки комментариев начинаются с символа "#"

# (пустые строки игнорируются).

# Строки, начинаю щ иеся с символа "&", позволяют

# включить компьютеры в среду PVM позднее. Если

# имя компьютера не предваряется символом "&",

# этот компьютер включается в среду PVM

# автоматически.

flavius marcus

&cambius lo=romulus &karsius

# Символ означает стандартные опции для

# следую щ их компьютеров

# dx=/export/home/fred/pvm3/lib/pvmd &octavius

# Если компьютеры являются частью типичного

# linux-кластера, то их имена можно использовать

# для включения узлов кластера в среду PVM

# вместе с другими узлами. _

Поскольку доступ к PVM-средствам обеспечивается через коллекцию библиотечных функций, С++-программа использует PVM как любую другую библиотеку. Следует иметь в виду, что каждая PVM-програм м а представляет собой автономную C++-программу с собственной функцией main (). Это означает, что все PVM-программы имеют собственное адресное пространство. При порождении каждой PVM-задачи создается ее собственный процесс с новым а д ресным пространством и, соответственно, идентификационный номер процесса. PVM-процессы ви д имы для утилиты ps. Несмотря на то что несколько PVM-задач могут выполняться вместе для решения некоторой пробле м ы, они будут иметь собственные копии динамической C++-библиотеки. Каждая программа имеет собственный поток iostream, библиотеку шаблонов, алгоритмы и пр. В область видимости глобальных С++-пере м енных адресное пространство не попадает. Это означает, что глобальные переменные одной PVM-задачи невидимы для других PVM-задач. Для взаимодействия отдельных задач используется м еханизм передачи сооб щ ений. Этим они отличаются от многопоточных программ, в которых потоки разделяют одно адресное пространство и могут взаимодействовать посредством глобальных переменных и передачи параметров. Если PVM-программы выполняются на одном компьютере с несколькими процессорами, то как дополнительные средства коммуникации программы могут совместно использовать файловую систе м у, каналы, FIFO-очереди и об щ ую па м ять. Несмотря на то что передача сооб щ ений — основной метод взаимодействия между PVM-задачами, ничто не мешает им в качестве дополнительных средств использовать файловую систе м у, буфер об м ена или даже аргументы командной строки. PVM-библиотека не ограничивает, а расширяет возможности динамической С++-библиотеки.

Работу, которую выполняет С++-программа, можно распределить между функциями, объектами или их сочетаниями. Действия, выполняемые программой, обычно делятся на такие логические категории: операции ввода-вывода, интерфейс пользователя, обработка базы данных, обработка сигналов и ошибок, числовые вычисления и т.д. Отделяя код интерфейса пользователя от кода обработки файлов, а также код процедур печати от кода числовых вычислений, мы не только распределяем работу програ м мы между функциями или объектами, но и стараемся выделять категории действий в соответствии с их характером. Логические группы организуются в библиотеки, модули, объектные шаблоны, компоненты и оболочки. Такой тип организации мы поддерживае м и при внесении PVM-задач в С++-програ мм у. Мы може м подойти к деко м позиции работ (work breakdown structure), используя м етод либо восходя щ его, либо нисходя щ его проектирования. В любом случае параллелиз м должен естественно вписываться в работу, которая на м ечена для выполнения функцией, модулем или объектом.

Не самая удачная идея — попытаться директивно навязать параллелиз м програ мм е. Искусственно насаждае м ый параллелиз м является причиной фор м ирования гро м оздкой архитектуры, которая, как правило, трудна для пони м ания и поддержки и создает сложности при определении корректности програ мм ы. Поэто м у, если програ мм а использует PVM-задачи, они должны быть результато м естественного разбиения программы. Каждую PVM-задачу следует отнести к одной из функциональных категорий. Например, если м ы разрабатывае м приложение, которое содержит обработку данных на естественном языке (Natural Language Processing — NLP), м еханиз м речевого воспроизведения текста (text-to-speech engine — TTS-engine) как часть интерфейса пользователя и формирование логических выводов как часть выборки данных, то параллелизм (естественный для NLP-компонента) должен быть представлен в виде задач внутри NLP-модуля или объекта, который отвечает за NLP-обработку. Аналогично параллелизм внутри компонента фор м ирования логических выводов следует представить в виде задач, составляю щ их модуль (объект или оболочку) выборки данных, отвечаю щ ий за выборку данных. Другими словами, мы идентифицируем PVM-задачи там, где они логически вписываются в работу, выполняемую программой, а не просто разбиваем работу программы на набор некоторых об щ их PVM-задач.

Соблюдение первичности логики и вторичности параллелизма имеет несколько последствий для С++-программ. Это означает, что мы могли бы порождать PVM-задачи из функции main() или из функций, вызываемых из функции main() (и даже из других функций). Мы могли бы порождать PVM-задачи из методов, прина д лежащих объектам. Место порождения задач зависит от требований к параллельности, выдвигаемых соответствую щ ей функцией, модулем или объектом. В об щ ем случае PVM-задачи можно разделить на две категории: SPMD (производная от SIMD) и MPMD (производная от MIMD). В модели SPMD все задачи будут выполнять одинаковый набор инструкций, но на различных наборах данных. В модели MPMD все задачи будут выполнять различные наборы инструкций на различных наборах данных. Но какую бы модель мы не использовали (SPMD или MPMD), создание задач должно происходить в соответствую щ их областях программы. Некоторые возможные конфигурации для порождения PVM-задач показаны на рис. 6.4.

Вариант 1 на рис. 6.4 представляет ситуацию, при которой функция main() порождает от 1 до N задач, причем каждая задача выполняет один и тот же набор инструкций, но на различных наборах данных. Су щ ествует несколько вариантов реализации этого сценария. В листинге 6.1 показана функция main(), которая вызывает функцию pvm_spawn().