Параллельное и распределенное программирование на С++

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(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

//.. .

setenv();

unsetenv();

putenv();

Если источники знаний реализуются в процессах, которые созданы с помощью функции posix_spawn () (или fork-exec), то их программирование не выходит за рамки обычного CORBA-программирования с доступом ко всех средствам, предлагаемым CORBA-протоколом.

Реализация модели «классной доски» с помощью глобальных объектов