Читать онлайн «Параллельное и распределенное программирование на С++». Страница 134

Таблица 13.1. Четыре типа параллельного доступа, используемых в модели «классной доски»

EREW  Exclusive Read Exclusive Write (монопольное чтение и монопольная запись)

CREW  Concurrent Read Exclusive Write (параллельное чтение и монопольная запись)

ERCW  Exclusive Read Concurrent Write (монопольное чтение и параллельная запись)

CRCW  Concurrent Read Concurrent Write (параллельное чтение и параллельная запись)

При разделении «классной доски» на части будет определено, какие из типов параллельности (см. табл. 13.1) подходят больше всего. Самый гибкий тип (CRCW) доступа может быть достигнут в зависимости от структуры «классной доски». Например, если используется 16 источников знаний, и каждый из них получает доступ к собственному сегменту «классной доски», то такие источники знаний могут параллельно считывать данные с «классной доски» и записывать их туда, не испытывал проблем «гонки» данных.

Следующий уровень управления включает выбор источников знаний. При этом определяется, какие из них следует включить в поиск решения и какие аспекты задачи им поручить. На этом уровне управления принимается решение перенести центр (фокус) внимания на ту или иную область задачи, что и определяет выбор соответствующих источников знаний. При решении задач любого типа всегда ставятся сле-лующие вопросы: «с чего начать?» и «что нужно для этого знать?». Уровень центра внимания отвечает за начальные условия задачи, а также определяет, какие источники знаний необходимо использовать и в какой момент они должны «вступить в игру». «Классной доске» должно быть известно, какими источниками знаний она может располагать, и обычно источники знаний принимают сообщения или параметры, которые предписывают, как им действовать или в какой области пространства решений следует начинать поиск. Для параллельных реализаций этот уровень управления определяет базовую модель параллелизма (распределение решателей задачи). Обычно для «классной доски» используется модель MPMD (Multiple Programs Multiple Data — множество программ и множество потоков данных), известнал также как MIMD (multiple-instruction, multiple-data — множество потоков команд и множество потоков данных), поскольку каждый источник знаний (решатель задачи) имеет собственную область специализации. Однако сама природа задачи иногда может дать право на использование такой популярной модели, как SPMD (Single Program Multiple Data —одна програ мм а, неско л ько потоков дан н ых). В это м с л учае урове н ь управ л е н ия породит N одинаковых источников знаний, но передаст им различные параметры.

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

Обратите внимание на то, что в первой из представленных конфигураций (см. рис. 13.4) механизм управления содержится в самой «классной доске», а не в отдельном модуле и не в источниках знаний. В этой конфигурации блок управления проектируется как часть класса «классной доски». Поскольку на уровнях 2 и 3 необходимо двустороннее взаимодействие, имеет смысл, чтобы «классная доска» порождала процессы или потоки, которые будут содержать источники знаний. Если «классная доска» порождает процессы или потоки, ей нетрудно получить доступ к идентификационному номеру любого потока или процесса. Это позволяет «классной доске» легко передавать сообщения источникам знаний и осуществлять управление процессами и потоками. Если «классной доске» по некоторой причине нужно прекратить деятельность конкретного источника знаний, то доступ к идентификатору потока или процесса делает эту задачу очень простой. Обратите внимание на то, что в одном из представленных на рис. 13.4 вариантов блок управления яв л яется внешни м по отношению к «к л ассной доске» и источника м зна н ий. В это м случае иде н тификационный но м ер потока и л и процесса должен быть явным образом связан с модулями управления.

Рис. 13.4. Конфигурации управления и их уровни в архитектуре «классной доски»

Реализация модели «классной доски» с помощью CORBA-объектов

Вспомните, что CORBA-объект (см. главу 8) является независимым от платформы распределенным объектом. К CORBA -объектам могут получать доступ процессы, выполняющиеся на одном или на разных компьютерах, подключенных к сети. Это делает CORBA-объекты кандидатами для использования в PVM-средах, когда программа делится на ряд процессов, которые могут (или не могут) выполняться на одном и том же компьютере. Обычно PVM-среда используется для передачи сообщений при вторичной роли общей памяти (если она вообще существует). Введение понятия разделяемого и доступного по сети объекта существенно усиливает вычислительные мощности PVM-среды. Следует иметь в виду, что с помощью CORBA-объектов можно смоделировать все, что позволяют смоделировать не распределенные объекты. Это означает, что PVM-задачи, которые имеют совместный доступ к CORBA-объектам, могут получать доступ к контейнерным объектам, объектам оболочки, шаблонов, доменов и другим видам вспомогательных объектов. В данном случае мы хотели бы, чтобы PVM-задачи имели доступ к объектам «классной доски». Поэтому модель передачи сообщений мы дополняем совместным доступом к сложным объектам. Помимо PVM-задач, получающих доступ к распределенным CORBA-объектам, к ним также могут обращаться задачи, порожденные функциями posix_spawn() или fork-exec. Эти задачи выполняются в отдельных адресных пространствах одного и того же компьютера, но могут, тем не менее, связываться с CORBA-объектами, которые расположены либо на том же, либо на другом компьютере. Поэтому, несмотря на то что все задачи, созданные с помощью функций posix_spawn () или fork-exec, должны размещаться на одном компьютере, CORBA-объекты могут располагаться на любом компьютере.