При выполнении этого вызова информация о курсах обучения записывается на «классную доску». Аналогично следующие методы
courses currentDegreePlan(); courses suggestedSchedule();
можно использовать для считывания информации с «классной доски». Поэтому для об щ ения с «классной доской» источнику знаний достаточно иметь ссылку на объект Black_board. Объект Black_board может располагаться в любом м есте сети intranet или Internet. Найти реальное м естоположение удаленного объекта — забота исключительно ORB-боркера. (Процесс отыскания и активизации CORBA-объектов расс м атривается в главе8.) Поскольку объект Black_board и м еет идентификационные но м ера PVM-задач, он м ожет управлять эти м и задачами и обмениваться сообщениями (отправлять и получать их) непосредственно с источниками знаний. Аналогично источники знаний могут напрямую взаимодействовать друг с другом, используя традиционный обмен PVM-сообщениями. Важно отметить следующее: после того как окажется, что не существует больше никаких системных PVM-вызовов, деструктор объекта Black_board должен вызвать м етод pvm_exit(), а каждый источник знаний — м етод pvm_exit (). Те м са м ы м из PVM-среды будут удалены ненужные больше объекты, но обработкаданных, не связанная с эти м и объекта м и, м ожет продолжаться.
Активизация источников знаний с помощью POSIX-функции spawn()
Реализация источников знаний в ра м ках PVM-задач особенно полезна в ситуации, если задачи должны выполняться на разных компьютерах. Каждый источник знаний в этом случае может воспользоваться преимуществами любого специализированного ресурса, которым может быть оснащен конкретный компьютер. К таким ресурсам можно отнести быстродействующий процессор, базу данных, специальное периферийное оборудование и наличие нескольких процессоров. PVM-задачи можно также использовать на одном компьютере с несколькими процессорами. Но поскольку взаимодействие с нашей «классной доской» легко реализовать путем подключения к порту, для реализации источников знаний, не мудрствуя лукаво, мы можем также использовать традиционные UNDC/Linux-процессы. Если источники знаний создаются в стандартных UNIX/Linux-процессах, а компьютер содержит несколько процессоров, то источники знаний могут выполняться параллельно на этих процессорах. Но если источников знаний больше, чем процессоров, возникает необходимость в многозадачности. На рис. 13.6 показаны два простых архитектурных варианта, которые можно использовать с CORBA-ориентированной «классной доской» и 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);
