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

set<long> SuggestionForElective;

courses Schedule; courses DegreePlan;

public:

blackboard(void); ~blackboard(void);

void suggestionsForMajor(const courses &X);

void suggestionsForMinor(const courses &X);

void suggestionsForGeneral(const courses &X);

void suggestionsForElectives(const courses &X);

courses *currentDegreePlan(void);

courses *suggestedSchedule(void);

//. . .

} ;

Этот класс реализации используется для предоставления реальных определений методов, объявленных в интерфейсном классе. Помимо реализации методов, производный класс может содержать компоненты данных, поскольку они не объявлены в качестве интерфейса. Обратите внимание на то, что класс реализации black_board, представленный в листинге 13.2, наследует непосредственно не интерфейсный класс black_board, а класс POA_black_board, который является одним из тех классов, которые создает IDL-компилятор от имени интерфейсного класса black_board. Объявление класса POA_black_board приведено в листинге 13.3.

// Листинг 13.3. Фрагмент объявления класса POA_black_board,

// созданного idl-компилятором для

// интерфейсного класса black_board

class POA_black_board : virtual public PortableServer::StaticImplementation

{

public:

virtual -POA_black_board (); black_board_ptr _this ();

bool dispatch (CORBA::StaticServerRequest_ptr); virtual void invoke (CORBA::StaticServerRequest_ptr); virtual CORBA::Boolean _is_a (const char *); virtual CORBA::InterfaceDef_ptr _get_interface (); virtual CORBA::RepositoryId _primary_interface

(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. По типу задач, порождае м ых в конструкторе, м ожно определить, с каки м и и м енно задача м и будет работать «классная доска»: с POSIX-потока м и, традиционны м и UNIX/Linux-процесса м и или PVM-задача м и.

Порождение источников знаний с помощью 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.