Активизация источников знаний с помощью POSIX-функции spawn()

Реализация источников знаний в ра м ках PVM-задач особенно полезна в ситуации, если задачи должны выполняться на разных компьютерах. Каждый источник знаний в этом случае может воспользоваться преимуществами любого специализированного ресурса, которым может быть оснащен конкретный компьютер. К таким ресурсам можно отнести быстродействующий процессор, базу данных, специальное периферийное оборудование и наличие нескольких процессоров. PVM-задачи можно также использовать на одном компьютере с несколькими процессорами. Но поскольку взаимодействие с нашей «классной доской» легко реализовать путем подключения к порту, для реализации источников знаний, не мудрствуя лукаво, мы можем также использовать традиционные UNDC/Linux-процессы. Если источники знаний создаются в стандартных UNIX/Linux-процессах, а компьютер содержит несколько процессоров, то источники знаний могут выполняться параллельно на этих процессорах. Но если источников знаний больше, чем процессоров, возникает необходимость в многозадачности. На рис. 13.6 показаны два простых архитектурных варианта, которые можно использовать с CORBA-ориентированной «классной доской» и UNIX/Linux-процессами.

В варианте 1 CORBA-объект и источники знаний размещаются на одном компьютере, и каждый источник знаний имеет собственное адресное пространство. Другими словами, каждый источник знаний порожден с помощью функции posix_spawn() или семейств а функций fork-exec. В варианте 2 CORBA-объект размещается на одном компьютере, а все источники знаний — на другом, но в различных адресных пространствах. В обоих вариантах CORBA-объект действует как разновидность общей памяти для источников знаний, поскольку все они получают доступ к нему и могут обмениваться информацией через «классную доску». При этом важно помнить о существовании основного преимущества CORBA-объекта — он имеет более высокую организацию, чем простой блок памяти. «Классная доска» — это объект, который может состоять из структур данных любого типа, объектов и даже других «классных досок». Такой вид организации не может быть реализован простым использованием базовых функций доступа к общей памяти. Поэтому CORBA-реализация обеспечивает идеальный способ разделения сложных объектов между процессами. В подразделе 13.5.3.1 описано создание PVM-задач, которые реализуют источники знаний. Здесь мы изменяем конструктор, включал в него вызовы функции posix_spawn () (с той же целью можно использовать алгоритм for_each () и функциональный объект задачи для вызова функции posix_spawn()). В варианте 1 (см. рис. 13.6) «классная доска» может порождать источники знаний при реализации конструктора. Но в варианте 2 это невозможно, поскольку «классная доска» расположена на отдельном компьютере. Поэтому в варианте 2 «классной доске» для вызова функции posix_spawn () приходится прибегать к услугам посредника. Посредничество можно организовать разными способами, например, «классная доска» может вызвать другой CORBA-объект, расположенный на одном компьютере с источниками знаний. С той же целью можно использовать удаленный вызов процедуры (Remote Procedure Call — RPC) или MPI- либо PVM-задачу, которая должна вызвать программу, содержащую обращение к функции posix_spawn (). (Описание вызовов функции posix_spawn () приведено в главе 3.) Как можно использовать функцию posix_spawn() для активизации одного из источников знаний, показано в листинге 13.8.

// Листинг 13.8. Использование функции posix_spawn() для

// запуска источников знаний

#include < spawn.h> blackboard:: blackboard(void) {

//...

pid_t Pid;

posix_spawnattr_t M;

posix_spawn_file_actions_t N;

posix_spawn_attr_init(& M);

posix_spawn_file_actions_init(& N);

char *const argv[] = {«knowledge_source1», NULL};

posix_spawn(& Pid, «knowledge_source1», & N, & M, argv, NULL);

//...

}

В листинге 13.8 инициализируются атрибуты и действия, необходимые для порождения задач, после чего с помощью функции posix_spawn() создается отдельный процесс, который предназначен для выполнения источника знаний knowledge_source1. После создания этого процесса «классная доска» получает к нему доступ через его идентификационный номер, сохраняемый в параметре Pid. Кроме «классной доски», используемой в качестве средства связи, возможно и стандартное межпроцессное взаимодействие (IPC), если «классная доска» расположена на одном компьютере с источниками знаний. «Классная доска» — самый простой способ взаимодействия между источниками знаний, хотя в конфигурации размещения «классной доски» на отдельном компьютере можно использовать с этой целью сокеты. В этом случае управление, осуществляемое «классной доской» над источниками знаний, будет более жестким и обусловленным в любой момент времени содержимым «классной доски», а не сообщениями, передаваемыми непосредственно источникам знаний. Прямую пересылку сообщений легче реализовать при использовании «классной доски» в сочетании с PVM-задачами. В этом случае источники знаний сами настраивают себя на основе содержимого «классной доски». Но «классная доска» все же имеет определенный «рычаг»управления источниками знаний, поскольку ей «известны» идентификационные номера всех процессов, содержащих источники знаний. Как модель MPMD (MIMD), так и модель SPMD (SIMD), также поддерживаются использованием функции posix_spawn(). В листинге 13.9 представлен класс, который можно использовать в качестве объекта-функции при выполнении алгоритма for_each ().

// Листинг 13.9. Использование класса child_process как

// объекта-функции при запуске источников

// знаний

class child_process{

string Command;

posix_spawnattr_t M;

posix_spawn_file_actions_t N;

pid_t Pid;

//...

public:

child_process(void);

void operator()(string X);

void spawn(string X);

};

void child_process:: operator()(string X) {

//...

posix_spawnattr_init(& M);

posix_spawn_file_actions_init(& N);

Command.append(" /tmp/");

Command.append(X);

char *const argv[] = {const_cast< char*> (Command.data()), NULL};

posix_spawn(& Pid, Command.data(), & N, & M, argv, NULL);

Command.erase(Command.begin(), Command.end()); //...

}

Мы инкапсулируем атрибуты, необходимые для функции posix_spawn(), в классе child_process. Инкапсуляция всех данных, требуемых для вызова этой функции в классе, упро щ ает ее использование и обеспечивает естественный интерфейс с атрибутами процесса, который создается с ее помощью. Обратите внимание на то, что в классе child_process мы определили функцию operator () (см. листинг 13.9). Это означает, что класс child_process можно использовать в качестве функционального объекта при выполнении алгоритма for__each (). По мере того как «классная доска» решает, какие источники знаний необходимо активизировать для решения задачи, она сохраняет их имена в контейнере Solve. Позже при выполнении конструктора «классной доски» нужные источники знаний активизируются с помощью алгоритма for_each ().

// Конструктор.

//...

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 представлены три базовые конфигурации распределения процессов для «классной доски» и источников знаний.

Поскольку «классная доска» реализована в многопоточной среде, то для синхронизации доступа к «классной доске» можно использовать Pthread-мьютексы и переменные условий, которые необходимо инкапсулировать в интерфейсных классах, как описано в главе 11. Кроме того, для координации и синхронизации работы, выполняемой источниками знаний, можно использовать функции pthread_cond_signal () и pthread_cond_broadcast (). Поскольку «классная доска» сама создает потоки, ей будет нетрудно получить доступ к идентификационным номерам всех источников знаний. Это означает, что «классная доска» может при необходимости аннулировать поток, используя функцию pthread_cancel (). Кроме того, «классная доска» способна синхронизировать выполнение источников знаний с помощью функции pthread_join(). Помимо уже перечисленных достоинств многопоточной реализации (высокое быстродействие и простота использования потоков и глобального объекта «классной доски»), существует также проблема обработки ошибок и исключительных ситуаций.

В общем случае эта проблема решается проще в рамках одного процесса и одного компьютера, чем при использовании нескольких процессов и нескольких компьютеров. На рис. 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.