Параллельное и распределенное программирование на С++
Шрифт:
(const PortableServer::ObjectId &, PortableServer::POA_ptr);
virtual void * _narrow_helper (const char *); static POA_black_board * _narrow (
PortableServer::Servant); virtual CORBA::Object_ptr _make_stub (PortableServer::
POA_ptr,
CORBA::Object_ptr);
//.. .
virtual void suggestionsForMajor (const courses& Major)
= 0;
virtual void suggestionsForMinor (const courses& Minor)
= 0;
virtual void suggestionsForGeneral (
const courses& General) = 0;
virtual void suggestionsForElectives (
const courses& Electives) = 0;
virtual courses* currentDegreePlan = 0;
virtual courses* suggestedSchedule = 0;
//. . . protected:
POA_black_board {}; private:
POA_black_board (const POA_black_board &); void operator= (const POA_black_board &);
};
Обратите внимание на то, что класс в листинге 13.3 является абстрактны м,
virtual courses* suggestedSchedule = 0;
Это означает, что данный класс нельзя использовать напря м ую. Из него необходи м о вывести производный класс, в которо м будут определены реальные функции-члены для всех объявлений чисто виртуальных функций. Класс POA_black_board, представленный в листинге 13.2, содержит требуе м ые определения для всех чисто виртуальных функций-членов. Что касается нашего класса «классной доски*', то для реализации действий са м ой «доски» и источников знаний используются С ++-м етоды. Однако источники знаний реализованы частично в языке С++ и частично в языке логического про г ра мм ирования Prolog. [24] Но поскольку С++ под д ерживает мультиязыковую и мультипарадигматическую разработку, к средствам С++ можно вполне добавить достоинства языка Prolog. В С++ мы можем либо породить Prolog-задачи (с помощью posix_spawn - или fork-exec-функций), либо получить доступ к среде Prolog через ее интерфейс с незнакомыми языками программирования, который позволяет Prolog-среде общаться непосредственно с С++ и наоборот. Независимо от того, на каком языке создана реализация источников знаний — С++ или Prolog, объект «классной доски» должен взаимодействовать только с С++-методами.
Порождение источников знаний в конструкторе «классной доски»
«Классная доска» реализуется как распределенный объект, использующий CORBA-протокол. В данном случае одной из основных целей «классной доски» является порождение источников знаний. Это важный момент, поскольку «классная доска» должна иметь доступ к идентификационным номерам задач. Начальное состояние «классной доски» (оно устанавливается в конструкторе) включает информацию о студенте, его академической характеристике, текущем семестре, требованиях для получения диплома и т.д. С помощью «классной доски», исходя из начального состояния, определяется, какие источники знаний следует запустить в работу. Иначе говоря, оценив начальную задачу и исходное состояние системы, «классная доска» составляет список запускаемых на выполнение источников знаний. Каждый источник знаний имеет соответствующий двоичный файл, а для хранения имен этих файлов «классная доска» использует контейнер Solvers. Позже, при функционировании конструктора, с по м ощью функционального объекта (или объекта-функции) и алгоритма for_each порождаются источники знаний. Вспомните, что любой класс, в котором определена операторная функция operator, м ож н о испо л ьзовать как функциональный объект. Объекты-функции, как прави л о при м еняют сов м естно со стандартны м и алгорит м а м и в м есто функций и л и в допо л нение к ни м. Обычно везде, где м ожно использовать обычную функцию, ее м ожно за м енить объекто м– функцией. Чтобы определить собственный функциональный объект, необходи м о определить операторный м етод operator , придав е м у соответствующий с м ысл, указав список пара м етров и тип возвращае м ого и м значения. Наша CORBA-реализация «классной доски» м ожет под д ерживать источники знаний, реализованные с по м ощью PVM-задач, традиционных UNDC/Linux-задач или от д ельных потоков, использующих библиотеки POSIX thread.
Порождение источников знаний с помощью PVM-задач
Конструктор «классной доски» содержит следующий вызов алгоритма, for_each(Solve.begin,Solve.end, Task);
Алгоритм for_each применяет операторный метод объекта функции (созданного для класса задачи) к каждому элементу контейнера Solve. Этот метод используется для порождения источников знаний в соответствии с моделью MIMD, при реализации которой все источники знаний имеют различную специализацию и работают с различными наборами данных. Объявление этого класса задач приведено в листинге 13.4.
// Листинг 13.4. Объявление класса задачи
class task{
int Tid[4];
int N;
//. . .
public:
//. . .
task(void) { N = 0; } void operator(string X);
};
void task::operator(string X) {
int cc; pvm_mytid;
cc = pvm_spawn(const_cast<char *>(X.data),NULL,0,"",l,&Tid[N]);
N++;
}
blackboard::blackboard(void) {
task Task;
vector<string> Solve;
//.. .
// Determine which KS to invoke
//. . .
Solve.push_back(KS1);
Solve.push_back(KS2);
Solve.push_back(KS3);
Solve.push_back(KS4);
for_each(Solve.begin, Solve.end, Task);
}
Этот класс task инкапсулирует порожденный процесс. Он содержит идентификационный но м ер задачи (поскольку у нас используется PVM-задача). В случае при м енения стандартных UNDC/Linux-процессов или Pthread-потоков, он должен содержать идентификационный но м ер процесса или потока. Этот класс действует как интерфейс между создаваемым процессом или потоком и «классной доской». «Классная доска» здесь является основным компонентом управления. Она может управлять PVM-задачами с помощью их идентификационных номеров. Кроме того, «классная доска» может использовать групповые PVM-операции для синхронизации PVM-задач с использованием барьеров, организации PVM-задач в логические группы, которые должны отрабатывать определенные аспекты решаемой задачи, и сигнализации членов группы с помощью соответствующих тегов сообщений. Групповые PVM-операции перечислены и описаны в табл. 13.2.
Особый интерес для нашей «классной доски» представляют операции pvm_barrier и pvm_joingroup, поскольку существуют ситуации, в которых «классная доска» не запускает новые источники знаний до тех пор, пока определенная группа источников знаний не завершит свою работу. Для блокирования вызывающего процесса до нужного момента (до окончания обработки данных соответствующими источниками знаний) можно использовать операцию pvm_barrier . Например, «классная доска» в качестве консультанта по выбору курсов обучения не будет активизировать источник знаний, отвечающий за составление расписания, до тех пор, пока не представят свои предложения источники знаний, которые специализируются на основных, общеобразовательных, второстепенных и факультативных курсах. Поэтому «классная доска» будет использовать операцию pvm_barrier для ожидания завершения работы этой группы PVM-задач. На рис. 13.5 представлена UML-диаграмма видов деятельности, которая позволяет понять, как синхронизируются источники знаний и «классная доска».
Барьер синхронизации здесь реализуется с помощью операций pvm_barrier и pvm_joingroup . Реализация операторной функции для объекта задачи приве д ена в л истин г е 13.5.
Таблица 13.2. Групповые PVM-операции
int pvm_joingroup (char *groupname); Вносит вызывающий процесс в группу groupname, а затем возвращает int-значение, которое представляет собой номер процесса в этой группе
int pvm_lvgroup (char *groupname); Удаляет вызывающий процесс из группы groupname
int pvm_gsive (char *groupname); Возвращает int-значение, которое представляет собой количество членов в группе groupname
int pvm_gettid (char *groupname, int inum); Возвращает int-значение, равное идентификационному номеру задачи, выполняемой процессом, который идентифицируется именем группы groupname и номером экземпляра inum
int pvm_getinst (char *groupname, int taskid); Возвращает int-значение, которое представляет собой номер экземпляра, связанный с именем группы groupname и процессом, выполняющим задачу с идентификационным номером taskid