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

• Компиляторы

• Интерпретаторы ко м анд

• Обработчики естественных языков

• Програ мм ы шифрования-дешифрирования

• Упаковка-распаковка

• Протоколы пересылки файлов

• Графические интерфейсы пользователей

• Контроллеры устройств

Корректная разработка каркасного класса language_processsor(при надлежащем его тестировании и отладке) позволяет ускорить разработку широкого диапазона приложений.

Понятие каркасного класса также полезно использовать при разработке приложений, к которым предъявляются требования параллелизма. Так, использование агент-ных каркасов и каркасов «классной доски» фиксирует базовую структуру параллелизма и схемы работы в этих структурах. Майкл Вулдридж в своей книге [51] предлагает следующий обобщенный цикл управления агентами.

Алгоритм: цикл управления агентами

В = ВО

while true do

get next percept p

В = brf(B,p)

I = deliberate(B)

П= plan(B,I)

execute(П)

end while_

Эта модель поведения реализуется широким диапазоном рациональных агентов. Если вы разрабатываете программу, в которой используются рациональные агенты, то скорее всего эта последовательность действий будет реализована в вашей программе. На фиксации последовательностей действий такого типа и «специализируются» каркасные классы. Для цикла управления агентами функции brf (), deliberate() и plan() должны быть объявлены чисто виртуальными функциями. Цикл управления агентами определяет, в каком порядке и как должны вызываться эти функции, а также сам факт того, что они должны быть вызваны. Однако конкретное содержание функции определит производный класс. При надлежащем определении цикла управления агентами будет решен целый класс проблем. Ведь системы, состоящие из множества параллельно выполняющихся агентов, постепенно становятся стандартом для реализации приложений параллельного программирования. Такие системы часто называют мультиагептпыми системами. Агентно-ориентированные системы мы рассмотрим в главе 12, а пока отметим, что агентные каркасные классы позволяют понизить уровень сложности разработки мультиагентных систем, что очень ценно в свете того, что мультиагентные системы становятся предпочтительным вариантом архитектуры для реализации средне- и крупномасштабных приложений, которые требуют реализации параллелизма или массового параллелизма.

Каркасные классы обеспечивают своих потомков не только планом действий (что весьма полезно для параллельных или распределенных систем), но и такими компонентами синхронизации, как объектно-ориентированные мьютексы, семафоры и потоки сообщений. Структура «классной доски» — полезное средство для взаимодействия множества агентов— представляет собой критический раздел, поскольку сразу несколько агентов должны иметь возможность одновременно считывать из нее информацию и записывать ее туда. Следовательно, каркасный класс должен обеспечить базовую структуру для отношений между агентами, компонентами синхронизации и»классной доской». Например, листинг 11.25 содержит два метода, которые каркасный класс мог бы использовать для доступа к «классной доске».

// Листинг 11.25. Определение методов recordMessge() и

// getMessage() для класса agent_framework

int agent_framework::recordMessage(void) {

Mutex.lock();

BlackBoardStream << Agent[N].message(); Mutex.unlock();

}

int agent_framework::getMessage(void) {

}

Mutex.lock();

BlackBoardStream » Values; Agent[N].perceive(Values); Mutex.unlock();

Здесь каркасный класс должен защищать доступ к «классной доске» с помощью объектов синхронизации. Поэтому, когда агенты считывают сообщения с «классной доски» или записывают их туда, синхронизация уже будет обеспечена каркасным классом. Программисту не нужно беспокоиться о синхронизации доступа к «классной доске». Базовая структура агентно-ориентированного каркасного класса agent_framework показана на рис. 11.11.

Обратите внимание на то, что каркасный класс инкапсулирует объектно-ориентированные мьютексы и переменные условий. Агентно-ориентированный каркасный класс (см. рис. 11.11) для организации взаимодействия процессов в MPI- либо PVM-ориентированной системе должен использовать MPI- либо PVM-потоки сообщений. Вспомните, что эти потоки сообщений были разработаны как интерфейсные классы, что позволяет программисту для доступа к PVM- или MPI-классу использовать iostreams-представление. Если MPI- или PVM-классы не используются, агенты могут взаимодействовать через сокеты, каналы или даже общую память. В любом случае мы рекомендуем реализовать примитивы синхронизации с помощью интерфейсных классов, которые упрощают их использование. Структура «классной доски», показанная на рис. 11.11, является объектно-ориентированной и использует преимущества универсальности, обеспечиваемой шаблонными классами, что также упрощает реализацию параллелизма. Агенты, выполняемые параллельно, представляют эффектив-кую модель параллельного и распределенного программирования.

Проблемы параллельного программирования, представленные в главе 2, можно эффективно решить, используя «строительные блоки», рассмотренные в этой главе. Роль интерфейсного класса в упрощении использования библиотек функций трудно преувеличить. Интерфейсный класс вносит логичность API-интерфейса путем заключения в оболочку вызовов функций из таких библиотек, как MPI или PVM. Интерфейсные классы обеспечивают типовую безопасность и возможность многократного использования кода, а также позволяют программисту работать в привычной «системе координат», как с PVM- или MPI-потоками данных. Межпроцессное взаимодействие (IPC) упрощается путем связывания канала или потоков сообщений сюБЧгеатБобъектами и перегрузки операторов вставки («) и извлечения (») для пользовательских классов. Класс ostream_iterator доказывает свою полезность в «оптовой» пересылке контейнерных объектов и их содержимого между процессами. Итераторы типа ostream_iterator и istream_iterator также обеспечивают свя-зующее звено между стандартными алгоритмами и IPC-компонентами и методами. Поскольку модель передачи сообщений используется во многих параллельных и распределенных приложениях, то любой метод, который упрощает передачу различных типов данных между процессами, упрощает программирование приложения в целом. К таким способам упрощения относится использование iostreams-классов и итераторов типа ostream_iterator и istream_iterator. Каркасный класс представлен здесь как базовый строительный блок параллельных приложений. Мы рассматриваем классы, подобные классам мьютексов, переменных условий и потоков, как компоненты низкого уровня, которые должны быть скрыты от программиста в каркасном классе (где это возможно!). При создании средне- и крупномасштабных приложений, которые тре-буют реализации параллелизма, программист не должен «застревать» на этих низкоуровневых компонентах. В идеале для удовлетворения требований параллельной обработки каркасный класс должен быть строительным блоком базового уровня и обеспечивать нас «готовыми» схемами равноправных элементов и взаимодействия типа «клиент-сервер». Мы можем использовать различные типы каркасных классов: для обработки чисел, баз данных или применения агентов, технологии «классной доски», GUI и т.д.