Шрифт:
// Конструктор.
//...
child_process Task;
for_each(Solve.begin, Solve.end, Task);
При выполнении этого конструктора для каждого элемента контейнера Solve вызывается метод operator , код которого приведен в листинге 13.9. После активизации источники знаний получают доступ к ссылке на объект «классной доски» и могут приступать к решению свой части задачи. И хотя источники знаний здесь не являются PVM-задачами, они связываются с «классной доской» таким же способом (см. подраздел 13.5.3.2) и так же выполняют свою работу. Дело в том, что межпроцессное взаимодействие между стандартными UNIX/Linux-процессами отличается от межпроцессного взаимодействия, которое возможно с использованием PVM-среды. Кроме того, PVM-задачи могут располагаться на разных компьютерах, в то время как процессы, созданные с помощью функции posix_spawn, могут существовать только на одном и том же компьютере. Если процессы, созданные функцией posix_spawn (либо семейством функций fork-exec), необходимо использовать в сочетании с моделью SIMD, то в дополнение к объекту «классной доски» для назначения источникам знаний конкретных областей задачи, которые они должны решать, можно использовать параметры argc и argv. В случае, когда «классная доска» находится на одном компьютере с источниками знаний, и она активизирует источники знаний в своем конструкторе, то формально «классная доска» является для них родителем, а потомки наследуют от родителя переменные среды. Переменные среды «классной доски» можно использовать в качестве еще одного способа передачи информации источникам знаний. Этими переменными среды можно легко управлять, используя следующие функции.
#include <stdlib.h>
//.. .
setenv;
unsetenv;
putenv;
Если источники знаний реализуются в процессах, которые созданы с помощью функции posix_spawn (или fork-exec), то их программирование не выходит за рамки обычного CORBA-программирования с доступом ко всех средствам, предлагаемым CORBA-протоколом.
Реализация модели «классной доски» с помощью глобальных объектов
Выбор CORBA-ориентированной «классной доски» вполне естествен в условиях, когда источники знаний должны быть реализованы в среде intranet или Internet, или когда в целях соблюдения модульного принципа организации, инкапсуляции и так далее каждый источник знаний реализуется в отдельном процессе. Однако в распределении «классной доски» необходимость возникает не всегда. Если источники знаний можно реализовать в рамках одного процесса или на одном компьютере, то лучше всего в этом случае организовать несколько потоков, поскольку при таком варианте быстродействие выше, расходы системных ресурсов меньше, а сама работа (настройка) — проще. Взаимодействие между потоками легче организовать, поскольку потоки разделяют одно адресное пространство и могут использовать глобальные переменные. Ведь тогда «классную доску» можно реализовать как глобальный объект, доступный всем потокам в процессе. При реализации источников знаний в виде потоков в рамках одной программы отпадает необходимость в межпроцессном взаимодействии, использовании сокетов или какого-либо другого типа сетевой связи. Кроме того, в этом случае оказывается ненужным дополнительный уровень CORBA-протокола, поскольку можно обойтись разработкой обычных C++-классов. Если многопоточная программа рассчитана на использование одного компьютера с несколькими процессорами, то потоки могут выполняться параллельно на доступных процессорах. В SMP- и МРР-системах потоковая конфигурация «классной доски» весьма привлекательна. В общем случае при использовании потоков достигается самая высокая производительность. Потоки часто называют облегченными процессами, поскольку они не требуют таких же расходов системных ресурсов, как традиционные UNIX/Linux-процессы. В библиотеке POSIX threads (Pthreads) предусмотрено практически все, что нужно для создания источников знаний и управления ими. На рис. 13.7.1-13.7.3 представлены три базовые конфигурации распределения процессов для «классной доски» и источников знаний.
Рис. 13.7. Базовая конфигурация распределения процессов для «классной доски» и источников знаний
Поскольку «классная доска» реализована в многопоточной среде, то для синхронизации доступа к «классной доске» можно использовать Pthread-мьютексы и переменные условий, которые необходимо инкапсулировать в интерфейсных классах, как описано в главе 11. Кроме того, для координации и синхронизации работы, выполняемой источниками знаний, можно использовать функции pthread_cond_signal и pthread_cond_broadcast . Поскольку «классная доска» сама создает потоки, ей будет нетрудно получить доступ к идентификационным номерам всех источников знаний. Это означает, что «классная доска» может при необходимости аннулировать поток, используя функцию pthread_cancel . Кроме того, «классная доска» способна синхронизировать выполнение источников знаний с помощью функции pthread_join. Помимо уже перечисленных достоинств многопоточной реализации (высокое быстродействие и простота использования потоков и глобального объекта «классной доски»), существует также проблема обработки ошибок и исключительных ситуаций.
В общем случае эта проблема решается проще в рамках одного процесса и одного компьютера, чем при использовании нескольких процессов и нескольких компьютеров. На рис. 13.8 показаны уровни сложности, связанные с обработкой ошибок и исключительных ситуаций при использовании различных конфигураций.
Рис. 13.8. Уровни сложности при обработке ошибок и исключений
Если источники знаний реализованы в отдельных потоках одного и того же процесса, то обработка возможных ошибок или исключительных ситуаций в этом случае относится к уровню сложности 2. Эту степень сложности необходимо учитывать еще на этапах проектирования и разработки программы, особенно в случае, если она требует параллельного программирования. Простейшее архитектурное решение, использующее модель «классной доски», состоит в реализации «классной доски» в виде глобального объекта, а источников знаний — в виде потоков. Рассмотрим фрагмент объявления класса blackboard.
// Листинг 13.10. Фрагмент объявления класса blackboard,
// разработанного для многопоточной среды
class blackboard{ protected: //.. .
set<long> SuggestionForMajor;
set<long> SuggestionForMinor;
set<long> SuggestionForGeneral;
set<long> SuggestionForElective;
set<long> Schedule;
set<long> DegreePlan;
mutex Mutex[10];
//.. .
public:
blackboard(void) ;
~blackboard(void);
void suggestionsForMajor(set<long> &X);
void suggestionsForMinor(set<long> &X);
void suggestionsForGeneral(set<long> &X);
void suggestionsForElectives(set<long> &X);
set<long> currentDegreePlan(void);
set<long> suggestedSchedule(void);
//.. .
};
Класс blackboard предназначен для реализации в качестве глобального объекта, к которому смогут получать доступ все потоки в программе. Обратите внимание на то, что класс blackboard в листинге 13.10 включает массив мьютексов. Эти мьютексы используются для защиты критических разделов «классной доски». При реализации источников знаний практически нет необходимости беспокоиться о синхронизации доступа к критическим разделам, поскольку код синхронизации инкапсулирован в классе blackboard.
Активизация источников знаний с помощью потоков
В этом разделе рассматривается реализация источников знаний в отдельных потоках. Потоки создаются здесь при выполнении конструктора класса «классной доски» (blackboard), и каждому потоку назначается конкретный источник знаний. Тем самым реализуется модель MIMD. Фрагмент кода конструктора класса blackboard приведен в листинге 13.11.
// Листинг 13.11. Конструктор класса blackboard,
// используемый для создания потоков,
// содержащих источники знаний
blackboard::blackboard(void) {
pthread_t Tid[4];
//.. .
try{
pthread_create(&Tid[0],NULL,suggestionForMajor, NULL);
pthread_create(&Tid[l],NULL, suggestionForMinor, NULL);
pthread_create(&Tid[2], NULL,suggestionForGeneral, NULL);
pthread_create(&Tid[3],NULL, suggestionForElective, NULL);
pthread_join(Tid[0],NULL);
pthread_join(Tid[l],NULL);