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

12.5. Мультиагентные системы

Мультиагентные системы— это системы, в которых задействовано несколько агентов, обладающих способностью в процессе решения некоторой задачи взаимодействовать, сотрудничать, «договариваться» или соперничать. У С++-разработчика программного обеспечения есть несколько вариантов для реализации мультиагентных систем. Агенты можно реализовать в отдельных потоках выполнения с помощью API-интерфейса POSIX thread. В этом случае одна программа разбивается на несколько потоков, каждый из которых содержит один или несколько агентов. Следовательно, агенты одного потока будут разделять одно и то же адресное пространство. Это позволяет агентам легко взаимодействовать путем использования глобальных переменных и простой передачи параметров. Если компьютер, на котором выполняется программа, содержит несколько процессоров, то агенты могут выполняться параллельно. В этом случае каждый агент должен быть оснащен объектами синхронизации (см. главы 5 и 11) и компонентами обработки исключительных ситуаций (см. главу7). Мультиагентные системы, реализованные посредством многопоточности, представляют самое простое решение, но тем не менее ограничивающее агентов рамками одного компьютера. Более гибкий подход к созданию мультиагентных систем предоставляет CORBA-реализация. Стандарт CORBA (помимо ядра спецификации CORBA) содержит спецификацию мультиагентного средства (multi-agent facility— MAF). MICO-реализацию, которую мы используем в CORBA-примерах этой книги, можно применять для реализации агентов, которые способны взаимодействовать через сети Internet, intranet и локальные сети. С++-привязка CORBA-стандарта имеет полную поддержку объектно-ориентированного представления и, следовательно, поддержку агентно-ориентированного программирования. В главе 13 мы рассмотрим, как можно использовать библиотеки PVM и MPI для поддержки агентов в контексте параллельного и распределенного программирования.

Агенты — это рациональные объекты. Агентно-ориентированное программирование — это свежий взгляд на старые проблемы декомпозиции, взаимодействия и синхронизации, которые являются обязательной частью каждого проекта параллельного или распределенного программирования. С++-поддержка перегрузки операторов контейнеров и шаблонов обеспечивает эффективные средства реализации широкого диапазона классов агентов. Будущие системы с массовым параллелизмом и большие распределенные системы будут опираться на агентно-ориентированные реализации поскольку практически не существует других путей построения таких систем. Несмотря на «вводный» характер примеров создания агентов, представленных в этой главе, они вполне обеспечивают основу для понимания практических принципов построения агентных систем. Для развертывания мультиагентных систем можно использовать об щ е д оступные и популярные библиотеки POSIX thread API, MICO, PVM и MPI. Мультиагентные системы можно использовать д ля реализации решений, которые требуют параллельного или распределенного программирования. В этой книге представлены два основных варианта архитектуры для параллельного и распределенного программирования: первый представляют агенты, а второй — «классные доски» (которые предполагают использование агентов). О том, как использовать «классные доски» для реализации решений параллельного и распределенного программирования, мы поговорим в следующей главе.

Одна из основных целей в параллельном программировании — разбить всю работу, предусмотренную для выполнения программой, на множество задач, которые могут при необходимости выполняться с определенной степенью параллелизма. Эта цель труднодостижима. Довольно сложно так провести декомпозицию работ (Work Breakdown Structure— WBS), чтобы создать соответствующий фундамент для параллелизма и обеспечить корректные и эффективные результаты работы. Для достижения этой цели мы используем методы моделирования и специальные архитектурные решения. На практике на этапе моделирования самой задачи и ее решения стараются выявить естественный параллелизм. Не следует в решение вносить параллелизм искусственно. Если задача и ее решение смоделированы надлежащим образом, то необходимый параллелизм обнаружится сам собой. Архитектура «классной доски» облегчает такой процесс моделирования. В частности, модель «классной доски» позволяет организовать и концептуализировать параллельность и взаимодействие компонентов в системе, которая требует применения параллельного или распределенного программирования.

Модель «классной доски» — это технология совместного решения задач. «Классная доска» используется для регистрации и координации действий, а также организации взаимодействия между двумя или больше программными решателями задач. Таким образом, в модели «классной доски» существует два основных типа компонентов: «классная доска» и решатели задач.

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