Параллельное и распределенное программирование на С++

Хьюз Камерон

Резюме

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

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

Метод, который мы предлагаем для реализации параллелизма, состоит в построении приложений на базе коллекции каркасных классов, которые уже оснащены надлежащими компонентами синхронизации, связанными соответствующими отношениями. В главах 12 и 13 мы подробнее остановимся на каркасных классах, которые поддерживают параллелизм. Мы также рассмотрим использование стандартных С++-алгоритмов, контейнеров и объектов функций для управления процессом создания множества задач или потоков в приложениях, требующих параллелизма.

Реализация агентно-ориентированных архитектур

Нам предстоит сделать еще немало, прежде чем мы поймем, как люди описывают свои задачи и какую роль эти описания играют в решении задач. Но мы уже знаем достаточно для того, чтобы предположить, что используемые людьми описания, представленные как в виде высказываний, так и в форме рисунков, могут быть сымитированы компьютерами. ГербертА. Саймон(Неrbеrt. Simon), Machine as Mind (Android Epistemology)

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

Что такое агенты

Когда объектное программирование впервые залвило о себе, сама трактовка понятия объекта вызвала большие споры. Подобные разногласия вызывает и трактовка понятия агента. Одни определяют агенты как автономные постоянно выполняющиеся про-траммы, которые действуют от имени пользователя. Однако это определение можно применить и к UNIX-демонам или даже некоторым драйверам устройств. Другие дополняют это определение тем, что агент должен обладать специальными знаниями пользователя, должен выполняться в среде, «населенной» другими агентами, и обязан действовать только в рамках заданной среды. Эти требования должны исключать другие программы, которые можно было бы до некоторой степени считать агентами. Например, многие агенты электронной почты действуют автономно и могут работать по многих средах. Кроме того, в различных кругах программистов для описания агентов появились такие термины, как софтбот, т.е. программный робот (softbot), база знаний (knowbot), программный брокер (software broker) и интеллектуальный

объект (smart object). В этой главе мы многократно будем определять термин агент. Начнем с простых согласованных частичных определений и построим определение, которое бы устраивало С++-программистов.

Существует определение, согласно которому агент определяется как некоторая сущность, функционирующая постоянно и автономно в среде, в которой выполняются другие агенты и процессы. Хотя весьма заманчиво принять это определение и развить его, мы не будем этого делать, поскольку оно «с таким же успехом» описывает и другие виды программных конструкций. Многие объектно-ориентированные компоненты функционируют постоянно и автономно в среде, в которой выполняются другие процессы и существуют другие агенты. И в самом деле, многие CORBA-ориентированные системы типа «клиент-сервер» вполне соответствуют этому описанию! Поэтому, если мы заменим в этом определении слово агент словом объект, оно в точности опишет многие объектно-ориентированные системы. Если заглянуть в более официальный источник, Foundation for Intelligent Physical Agents (FIPA), то в соответствии с ним термин агент определяется следующим образом:

Агент — это главный исполнитель в домене. Он обладает одной или несколькими сервисными возможностями, образующими единую и комплексную модель выполнения, которая может включать доступ к внешнему ПО, пользователям (людям) и средствам связи.

Несмотря на то что это определение имеет более структурированную форму, оно также нуждается в дальнейшем уточнении, поскольку под это определение попадают многие серверы (объектно-ориентированные и нет). Это определение в таком виде включило бы слишком много типов программ и программных конструкций. И хотя мы опираемся на FIPA-спецификацию, это базовое определение требует дальнейшей проработки.

Агенты: исходное определение

Одной из причин, по которой слово объект может заменить с л ово агент во многих определениях и описаниях агента, состоит в том, что агенты по сути основаны на объектах. И в самом деле, наше первое требование к определению агента заключается в том, что оно в первую очередь должно удовлетворять определению объекта ^[19], т.е. мы имеем в виду, что агент — это объект определенного вида. В этой главе особый акцент делается на том, что отличает агента от других категорий объектов. Исходя из того, что С++ поддерживает интерфейсные, контейнерные и каркасные классы, мы можем с таким же успехом ввести и агентные классы. Это приводит нас ко второму требованию, выдвигаемому к определению агентов в С++-среде. В С++ агент реализуется с использованием понятия класса. Типы классов отличаются друг от друга тем, как они функционируют, или тем, как они структурированы. Например, контейнерный класс описывает объект, используемый для хранения других объектов. Интерфейсный класс применяется для описания объекта, который преобразует или адаптирует интерфейс другого объекта. Каркасный класс описывает объект, который содержит шаблон, или образец поведения, являющегося общим для целого семейства других объектов. Агентные классы предназначены для определения объектов, которые обладают тем, что Иогав Шохам (Yohav Shoham) описывает как психическое (интеллектуальное) состояние: «Психическое состояние должно включать такие компоненты, как представления, возможности, варианты выбора и обязательства». Это психическое состояние зачастую описывается моделью убеждений, желаний и намерений (Belief, Desires and Intentions — BDI). Мы расширяем модель BDI, чтобы включить в нее действия. Теперь в нашем первом определении агент описывается как часть ПО, отвечающая следующим требованиям.

1. Это определенный тип объекта (т.е. не все объекты являются агентами).

2. Его реализация использует понятие класса (для агентов весьма существенны инкапсуляция, наследование и полиморфизм).

3. Он содержит набор поведенческих вариантов и атрибутов, которые должны включатьубеждения, желания, намерения идействия.

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

Типы агентов

Существует несколько категорий агентов. Несмотря на то что не все агенты можно отнести к одной из них, с их помощью все же можно описать большинство агентов, которые уже нашли практическое применение. В табл. 12.1 перечислено пять основных категорий агентов. Очевидно, существуют и агенты смешанного типа, которые можно отнести к нескольким категориям одновременно, поскольку для распределения агентов по категориям нет никаких жестких правил. Эти категории представлены для удобства и используются в качестве отправной точки в попытке классифицировать агенты, которые, возможно, вам придется разрабатывать или использовать в своей работе.