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

Хьюз Камерон

Существует множество архитектурных решений, которые поддерживают параллелизм. Архитектурное решение можно считать корректным, если оно соответствует декомпозиции работ (work breakdown structure — WBR) программного обеспечения (ДР ПО). Параллельные и распределенные архитектуры могут быть самыми разнообразными. В то время как некоторые распределенные архитектуры прекрасно работают в Web-среде, они практически обречены на неудачу в среде с реальным масштабом времени. Например, распределенные архитектуры, которые рассчитаны на длинные временные задержки, вполне приемлемы для Web-среды и совершенно неприемлемы для многих сред реального времени. Достаточно сравнить распределенную обработку данных в Web-ориентированной системе функционирования электронной почты с распределенной обработкой данных в банкоматах, или автоматических кассовых машинах (automated teller machine— ATM). Задержка (время

ожидания), которая присутствует во многих почтовых Web-системах, была бы попросту губительной для таких систем реального времени, как банкоматы. Одни распределенные архитектуры (имеются в виду некоторые асинхронные модели) справляются с временными задержками лучше, чем другие. Кроме того, необходимо самым серьезным образом подходить к выбору соответствующих архитектур параллельной обработки данных. Например, методы векторной обработки данных наилучшим образом подходят для решения определенных математических задач и проблем имитационного моделирования, но они совершенно неэффективны в применении к мультиагентным алгоритмам планирования. Распространенные архитектуры ПО, которые поддерживают параллельное и распределенное программирование, показаны в табл. 2.2.

Четыре базовые модели, перечисленные в табл. 2.2, и их вариации обеспечивают основу для всех параллельных типов архитектур (т.е. объектно-ориентированного, агентно-ориентированного и «классной доски»), которые рассматриваются в этой книге. Разработчикам ПО необходимо подробно ознакомиться с каждой из этих моделей и их приложением к параллельному и распределенному программированию. Мы считаем своим долгом предоставить читателю введение в эти модели и дать библиографические сведения по материалам, которые позволят найти о них более детальную информацию. В каждой работе или при решении проблемы лучше всего искать естественный или присущий им параллелизм, а выбранный тип архитектуры Должен максимально соответствовать этому естественному параллелизму . Например, параллелизм в решении, возможно, лучше описывать с помощью симметричной модели, или модели сети с равноправными узлами (peer-to-peer model), в которой все сотрудники (исполнители) считаются равноправными, в отличие от несимметричной Модели «управляющий/рабочий», в которой существует главный (ведущий) процесс, Управляющий всеми остальными процессами как подчиненными.

Модель

Архитектура

Распределенное программирование

Параллельное программирование

Модель ведущего узла, именуемая также:

Главный узел управляет задачами, т.е. контролирует их выполнение и передает работу подчиненным задачам

• главный/подчиненный;

• управляющий/рабочий;

• клиент/сервер

Модель равноправных узлов

Все задачи, в основном, имеют одинаковый ранг, и работа между ними распределяется равномерно

Векторная или конвейерная (поточная)обработка

Один исполнительный узел соответствует каждому элементу массива (вектора) или шагу конвейера

Дерево с родительскими и дочерними элементами

Динамически генерируемые исполнители в отношении типа «родитель/потомок». Этот тип архитектуры полезно использовать в алгоритмах следующих типов:

• рекурсия;

• «разделяй и властвуй»; •И/ИЛИ

• древовидная обработка

Различные методы тестирования и отладки

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

С параллельным и распределенным программированием все обстоит иначе. Здесь трудно воспроизвести точный контекст параллельных или распределенных

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

Связь между параллельным и распределенным проектами

При создании документации на проектирование параллельного или распределенного ПО необходимо описать декомпозицию работ и их синхронизацию, а также взаимодействие между задачами, объектами, процессами и потоками. При этом проектировщики должны тесно контактировать с разработчиками, а разработчики — с теми, кто будет поддерживать систему и заниматься ее администрированием. В идеале это взаимодействие должно осуществляться по действующим стандартам. Однако найти единый язык, понятный всем сторонам и позволяющий четко представить мультипарадигматическую природу всех этих систем, — трудно достижимая цель. Мы остановили свой выбор на языке UML (Unified Modeling Language — унифицированный язык моделирования). В табл. 2.3 перечислено семь UML-диаграмм, которые часто используются при создании многопоточных, параллельных или распределенных программ.

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

Таблица 2.3. UML-диаграммы, используемые при создании многопоточных, параллельных или распределенных программ

Диаграмма (видов) деятельности - разновидность диаграммы состояний, в которой большинство состояний (или все) представляют виды деятельности, а большинство переходов (или все) активизируются при выполнении некоторого действия в исходных состояниях

Диаграмма взаимодействия– Тип диаграммы, которая отображает взаимодействие между объектами. Взаимодействия описываются в виде сообщений, которыми они обмениваются. К диаграммам взаимодействия относятся диаграммы сотрудничества, диаграммы последовательностей и диаграммы (видов)деятельности

Диаграмма (параллельных) состояний– Диаграмма, которая показывает последовательность преобразований объекта в процессе его реакции на события. При использовании диаграммы параллельных состояний эти преобразования могут происходить в течение одного и того же интервала времени

Диаграмма последовательностей– Диаграмма взаимодействия, в которой отображается организация структуры объектов, принимающих или отправляющих сообщения (с акцентом на упорядочении сообщений по времени)