«Как только мы пересекаем черту, чтобы реализовать себя в компьютерной технологии, наши успехи начинают зависеть от способности нашего ума к эволюции. Мы становимся частью программного, а не аппаратного обеспечения.»

(Рей Курзвейл (Ray Kurzweil), The Age of Spiritual Machines )

При реализации параллелизма в программном обеспечении необходимо следовать одному важном)- правилу: параллелизм нужно обнаружить, а не внести извне. Иногда цель увеличения быстродействия программы не является достаточно оп-равданной для насаждения параллелизма в логику программы, которая по своей природе является последовательной. Параллелизм в проекте должен быть естественным следствием требований системы. Если параллельность определена в технических требованиях ксистеме, то следует с самого начала рассматривать варианты архитектуры и алгоритмы, которые поддерживают параллелизм. В противном случае необходимость паралле-лизма «всплывет» в уже существующей системе, которая изначально была нацелена лишь на выполнение последовательных действий. Такал участь часто постигает системы, которые первоначально разрабатывались как однопользовательские, а затем постепенно вырастали во многопользовательские, или системы, которые с функциональной точки зрения слишком далеко отошли от исходных спецификаций. В таких системах намерение внести в систему параллелизм можно сравнить с попыткой «махать руками после драки», и в этом случае для поддержки параллельности остается лишь делать архитектурные «пристройки». В этой книге мы описываем методы реализации естественного параллелизма. Другими словами, если мы знаем, что нам нужно обеспечить параллелизм, нас интересует, как это сделать, используя средства С++?

Мы представляем архитектурный подход к управлению параллелизмом в программе, используя преимущества С++-поддержки объектно-ориентированного программирования и универсальности. В частности, С++-средства поддержки наследования, полиморфизма и шаблонов успешно применяются для реализации архитектурных решений и программных компонентов, которые поддерживают параллельность. Методы объектно-ориентированного программирования обеспечивают поддержку десяти типов классов, перечисленных в табл. 11.1.

Таблица 11.1. Типы объектно-ориентированных классов

Шаблонный класс Обобщенный код, который может использовать любой тип; реальный тип является параметром для тела этого кода

Контейнерный класс Класс, используемый для хранения объектов во внутренней или внешней памяти

Виртуальный базовый класс Базовый класс, который служит прямой и/или косвенной основой для создания производных посредством множественного наследования; только одна его копия разделяется всеми его производными классами

Абстрактный класс Класс, который поддерживает интерфейс для производных классов и который может быть использован только в качестве базового; используется как макет для построения других классов

Интерфейсный класс Класс, который используется для установки интерфейса других классов

Узловой класс Класс, функции которого расширены за счет добавления новых членов к тем, которые были унаследованы от базового класса

Доменный класс Класс, созданный для имитации некоторого элемента в конкретной предметной области; значение класса связано с этой предметной областью

Составной класс Класс, который содержит другие классы; имеет с этими классами отношения типа «целое-часть»

Конкретный класс Класс, реализация которого определена, что позволяет объявлять экземпляры этого класса; он не предполагается для использования в качестве базового класса и не прелусматривает попыток создавать операции общего характера

Каркасный класс Класс (или коллекция классов), который имеет предопределенную структуру и представляет обобщенный характер функционирования

Безусловно, эти типы классов особенно полезны для проектов, в которых предполагается реализовать параллельность. Дело в том, что они позволяют внедрить принцип компоновки из стандартных блоков. Мы обычно начинаем с примитивных компонентов, используя их для построения классов синхронизации. Классы синхронизации позволят нам создавать контейнерные и каркасные классы, рассчитанные на безопасное внедрение параллелизма. Каркасные классы представляют собой строительные блоки, предназначенные для таких параллельных архитектур более высокого уровня, как мультиагентные системы и «доски объявлений». На каждом уровне сложность параллельного и распределенного программирования уменьшается благодаря использованию различных типов классов, перечисленных в табл. 11.1.

Итак, начнем с интерфейсного класса. Интерфейсный (или адаптерный) класс испоользуется для модификации или усовершенствования интерфейса другого класса или множества классов. Интерфейсный класс может также выступать в качестве оболочки, созданной вокруг одной или нескольких функций, которые не являются членами конкретного класса Такая роль интерфейсного класса позволяет обеспечить обьектно-ориентированный интерфейс с программным обеспечением, которое необязательно является объектно-ориентированным. Более того, интерфейсные классы позволяют упростить интерфейсы таких библиотек функций, как POSIX threads, PVM и MPI. Мы можем «обернуть» необъектно-ориентированную функцию в объектно-ориеитированный интерфейс; либо мы можем «обернуть» в интерфейсный класс некоторые данные, инкапсулировать их и предоставить им таким образом объектно-ориентированный интерфейс. Помимо упрощения сложности некоторых библиотек функций, интерфейсные классы используются для обеспечения разработчиков ПО согласующимся интерфейсом API (Application Programmer Interface). Например, С++-программисты, которые привыкли работать с iostream-классами, получат возможность выполнять операции ввода-вывода, оперируя категориями обьектно-ориентированпых потоков данных. Кривая обучения существенно минимизируется, если новые методы ввода-вывода описать в виде привычного iostream-представлеиия. Например, мы можем представить библиотеку средств передачи сообщений MPI как коллекцию потоков.

mpi_stream Stream1;

mpi_stream Stream2;

Streaml << Messagel << Message2 << Message3;

Stream2 >> Message4;

//. . .

Нри таком подходе программист может целиком сосредоточиться на логике программы и не ломать голову над соблюдением требований к синтаксису библиотеки MPI.

Зачастую полезно использовать инкапсуляцию, чтобы скрыть детали библиотек функций и обеспечить создание самодостаточных компонентов, которые годятся для многократного использования. Возьмем для примера мьютекс, который мы рассматривали в главе 7. Вспомним, что мьютекс— это переменная специального типа, ис-пользуемая для синхронизации. Мьютексы позволяют получать безопасный доступ к критическом) разделу данных или кода программы. Существует шесть основных функций, предназначенных для работы с переменной типа pthread_mutex_t (POSIX Threads Mutex).

Все эти функции принимают в качестве параметра указатель на переменную типа pthread_mutex_t. Для инкапсуляции доступа к переменной типа pthread_mutex_t и упрощения вызовов функций, которые обращаются к мьютексным переменным, можно использовать интерфейсный класс. Рассмотрим листинг 11.1, в котором объявляется класс mutex.

// Листинг 11.1. Объявление класса mutex

class mutex{ protected:

pthread_mutex_t *Mutex;

pthread_mutexattr_t *Attr; public:

mutex(void)

int lock(void);

int unlock(void);

int trylock(void);

int timedlock(void);

};

Объявив класс mutex, используем его для определения мьютексных пере м енных. Мы можем объявлять массивы мьютексов и использовать эти пере м енные как члены пользовательских классов. Инкапсулировав пере м енную типа • pthread_mutex_t и мьютексные функции, воспользуемся преимуществами методов объектно-ориентированного программирования. Эти мьютексные переменные можно затем применять в качестве аргументов функций и значений, возвра щ аемых функциями. А поскольку мьютексные функции теперь связаны с переменной типа pthread_mutex_t, то там, где мы используем мьютексную переменную, эти функции также будут доступны.

Функции-члены класса mutex определяются путем заключения в оболочку вызовов соответствующих Pthread-функций, например, так.

// Листинг 11.2. Функции-члены класса mutex

mutex::mutex(void) {

try{

int Value;

Value = pthread_mutexattr_int(Attr); //. . .

Value = pthread_mutex_init(Mutex,Attr); //. . .

\

}

int mutex::lock(void) {

int RetValue;

RetValue = pthread_mutex_lock(Mutex); //. . .

return(ReturnValue);

}

Благодаря инкапсуляции мы также защищаем переменные типа pthread_mutex_t * и pthread_mutexattr_t *. Другими словами, при вызове методов lock(), unlock(), trylock() и других нам не нужно беспокоиться о том, к каким мьютексным переменным или переменным атрибутов будут применены эти функции. Возможность скрывать информацию (посредством инкапсуляции) позволяет программисту писать вполне безопасный код. С помощью свободно распространяемых версий Рthread-функций этим функциям можно передать любую переменную типа pthread_mutex_t. Однако при передаче одной из этих функций неверно заданного мьютекса может возникнуть взаимоблокировка или отсрочка бесконечной длины. Инкапсуляция переменных типа pthread_mutex_t и pthread_mutexattr_t в к л ассе mutex предостав л яет программисту полный контроль над тем, какие функции получат доступ к этим переменным.

Теперь мы можем использовать такой встроенный интерфейсный класс, как mutex, в любых других пользовательских классах, предназначенных для безопасной обработки потоков выполнения. Предположим, мы хотели бы создать очередь с многопоточной поддержкой и многопоточный класс pvm_stream. Очередь будем использовать для хранения поступающих событий для множества потоков, образованных в программе. На некоторые потоки возложена ответственность за отправку сообщений различным PVM-задачам. PVM-задачи и потоки выполняются параллельно. Несколько потоков выполнения разделяют единственный PVM-класс и единственную очередь событий. Отношения между потоками, PVM-задачами, очередью событий и классом pvm_stream показаны на рис. 11.1.

Очередь, показанная на рис. 11.1, представляет собой критический раздел, поскольку она совместно используется несколькими выполняемыми потоками. Класс pvm_stream — это также критический раздел и по той же причине. Если эти критические разделы не синхронизировать и не защитить, то данные в очереди и классе pvm_stream могут разрушиться. Тот факт, что несколько потоков могут одновременно обновлять либо очередь, либо код класса pvm_stream, открывает среду для «гонок». Чтобы не допустить этого, мы должны обеспечить нашу очередь и к л асс pvm_stream встроенны м и средства м и блокировки и разблокировки. Эти средства также поддерживаются классом mutex. На рис. 11.2 показана диаграмма классов для наших пользовательских классов x_queue и pvm_stream.

Обратите внимание на то, что класс x_queue содержит к л асс мьютекс, т.е. между классами x_queue и мьютекс существует отношение агрегирования. Любая операция, которая изменяет состояние наше г о к л асса x_queue, может привести к «гонкам» данных, если, конечно, эгу операцию не синхронизировать. Следовательно, операции, которые добавляют объект в очередь или удаляют его из нее, являются кандидатами для синхронизации. В листинге 11.3 приведено объявление к л асса x_queue как шаблонного.

Рис.11.1. Отношения между потоками, PVM-задачами, очередью событий и классом pvm_stream в PVM-программе

Рис.11.2. Диаграмма классов для пользовательских классов x_queue и pvm_stream

// Листинг 11.3. Объявление класса x_queue

template <class T> x_queue class{

protected:

queue<T> EventQ;

mutex Mutex;

//...

public:

bool enqueue(T Object);

T dequeue(void);

//...

};

Метод enqueue() используется для добавления элементов в очередь, а метод dequeue() — для удаления их из очереди. Каждый из этих методов рассчитан на использование oбъeктaMutex. Определение этих методов приведено в листинге 11.4.

// Листинг 11.4. Определение методов enqueue() и dequeue()

tempIate<class T> bool x_queue<T>::enqueue(T Object)

{

Mutex.lock(); EventQ.push(Object); Mutex.unlock();

}

Leinplr.te<class T> T x_queue<T>::dequeue(void)

{

T Object; //. . .

Mutex.lock();

Object = EventQ.front()

EventQ.pop();

Mutex.unlock() ;

//. . .

return(Object);

}

Теперь очередь может функционировать (принимать новые элементы и избавляться от ненужных) в многопоточной среде. ПотокВ (см. рис.11.1) добавляет элементы в очередь, а потокА удаляет их оттуда. Класс mutex является интерфейсным классом. Он заключает в оболочку функции pthread_mutex_lock (), pthread_mutex_unlock (), pthread_mutex_init() и pthread_mutex_trylock(). Класс x_queue также является интерфейсным, поскольку он адаптирует интерфейс для встроенного класса queue<T> . Прежде всего, он заменяет интерфейсы методов push() и pop() методами enqueue() и dequeue() . При этом операции вставки и удаления элементов из очереди заключаются между вызовами методов Mutex.lock() и Mutex.unlock(). Поэтому в первом случае мы используем интерфейсный класс для инкапсуляции переменных типа pthread_mutex_t* и pthread_mutexattr_t*, а также заключаем в интерфейсную оболочку несколько функций из библиотеки Pthread. А во втором случае мы используем интерфейсный класс для адаптации интерфейса класса queue<T>. Еще одно достоинство класса mutex состоит в том, что его легко использовать в других классах, которые содержат критические разделы или области.

Класс pvm_stream (см. рис. 11 1) также является критическим разделом, поскольку оба потока выполнения (А и В) имеют доступ к потоку данных. Опасность возникновения «гонок» данных здесь вполне реальна, поскольку потокА и поток В могут получить доступ к потоку данных одновременно. Следовательно, мы используем класс mutex в нашем классе pvm_stream для обеспечения необходимой синхронизации.

// Листинг 11.5. Объявление класса pvm_stream

class pvm_stream{

protected:

mutex Mutex;

int TaskId;

int MessageId;

// . - -

public:

pvm_stream & operator <<(string X);

pvm_stream & operator «(int X);

pvm_stream &operator <<(float X);

pvm_stream &operator>>(string X);

//.. .

};

Как и в классе x_queue, объект Mutex используется применительно к функциям, которые могут изменить состояние объекта класса pvm_stream. Например, мы могли определить один из операторов "«" следующим образом .

// Листинг 11.6. Определение оператора << для

// класса pvm_stream

pvm_stream &pvm_stream::operator<<(string X) {

//...

pvm_pkbyte(const_cast<char *>(X.data()),X.size(),1);

Mutex.lock();

pvm_send(TaskId,MessageId);

Mutex.unlock();

//.. .

return(*this);

}

Класс pvm_stream использует объекты Mutex для синхронизации доступа к его критическому разделу точно так же, как это было сделано в классе x_queue. Важно отметить, что в обоих случалх инкапсулируются pthread_mutex-функции . Программист не должен беспокоиться о правильном синтаксисе их вызова. Здесь также используется более простой интерфейс для вызова функций lock () и unlock (). Более того, здесь нельзя перепутать, какую pthread_mutex_t*-nepeмeннyю нужно использовать с pthread_mutex-функциями. Наконец, программист может объявить несколько экземпляров класса mutex, не обращалсь снова и снова к функциям библиотеки Pthread. Раз мы сделали ссылку на Pthread-функции в определениях методов клlacca mutex, то теперь нам достаточно вызывать только эти методы.

Чтобы справиться со сложностью написания и поддержки программ с параллелизмом, попробуем упростить API-интерфейс с соответствующими библиотеками. В некоторых системах, возможно, имеет смысл создать библиотеки Pthreads, MPI, атакже стандартные функции использования семафоров и разделяемой памяти как часть единого решения. Все эти библиотеки и функции имеют собственные протоколы и синтаксис. Но у них есть много общего. Поэтому мы можем использовать интерфейсные классы, наследование и полиморфизм для создания упрощенного и непротиворечивого интерфейса, с которым непосредственно будет работать программист. Мы можем также скрыть от наших приложений детали реализации конкретной библиотеки. Если приложение опирается только на методы, используемые в наших интерфейсных классах, то оно будет защищено от изменений, вносимых в реализацию функций, обновлений библиотек и прочих «подводных» реструктуризации. В конце концов, работа над интерфейсом (интерфейсными классами) с компонентами параллелизма и библиотеками функций позволит существенно понизить уровень сложности параллельного программирования. Итак, рассмотрим подробнее, какие методы разработки интерфейсных классов можно реализовать для поддержки параллелизма.

Базовый POSIX-семафор используется для синхронизации доступа к критическому разделу нескольких процессов, а базовый POSIX -поток— для синхронизации доступа к критическому разделу нескольких потоков. В обоих случалх используются переменные синхронизации и ряд функций, работающих с этими переменными. Библиотеки MPI и PVM содержат примитивы передачи сообщений и обладают средствами порождения задач. Но интерфейсы этих библиотек различны. Нетрудно предположить, что работа прикладного программиста была бы эффективней, если бы он сосредоточил свое внимание на логике и структуре программы. Однако там, где семантика программы теряет свою ясность из-за необходимости использовать библиотеки, в которых попадаются аналогичные функции, а сами библиотеки отличаются синтаксисом и протоколами, у программиста возникают немалые трудности. Отсюда вытекает потребность универсализации интерфейса, который бы подходил для работы с разными библиотеками.

Существует по крайней мере два подхода к разработке общего интерфейса для семейства, или коллекции классов. Объектно-ориентированный подход начинается с общего и переходит к частностям посредством наследования. Другими словами, возьмем минимальный набор характеристик и атрибутов, которыми должен обладать каждый член рассматриваемого сехмейства классов, а затем посредством наследования будем конкретизировать характеристики для каждого класса. При таком подходе по мере «спуска» по иерархии классов интерфейс становится все более «узким». Второй подход часто используется в коллекциях шаблонов. Шаблонные методы начинаются c конкретного и переходят к более общему посредством «широких» интерфейсов. «Широкий» интерфейс включает обобщение всех характеристик и атрибутов (см. книгу Страуструпа « Язык программирования С++» , 1997). Если бы нам пришлось применить к библиотекам средств параллелизма «узкий» и «широкий» интерфейсы, то согласно метолу «узкого интерфейса» мы бы взяли от каждой библиотеки общие, или пересекающиеся, части (т.е. пересечение), обобщили их и поместили в базовый класс. И, наоборот, реализуя метод «широкого интерфейса», нужно было бы поместить в базовый класс все функциональные части каждой библиотеки (т.е. объединение), предварительно обобщив их. В результате пересечения мы получили бы меньший по объему да и менее полезный класс. А результат объединения, скорей всего, поразил бы каждого своей громоздкостью. Решение, которое интересует нас в данном случае, находится где-то посередине, т.е. нам нужны «полуширокие» интерфейсы. Начнем же мы с метода «узкого» интерфейса и обобщим его настолько, насколько это можно сделать в пределах иерархии одного класса. Затем используем этот «узкий» интерфейс в качестве основы для коллекции классов, которые связаны не наследованием, а функциями. «Узкий» интерфейс должен действовать в качестве стратегии сдерживания «ширины», до которой может разбухнуть «полуширокий» интерфейс. Другими словами, нам не нужно объединять буквально все характеристики и атрибуты; мы хотим получить объединение только тех частей, которые логически связаны с нашим «узким» интерфейсом. Проиллюстрируем эту мысль иа примере простого проекта интерфейсных классов для POSIX-семафора, Pthread-мьютекса и Pthread-переменной блокировки.

Безотносительно к реализации деталей, операции блокировки, разблокировки и «пробной» блокировки являются характеристиками переменных синхронизации. Поэтому мы создадим базовый класс, который будет служить «трафаретом» для целого семейства классов. Объявление класса synchronization_variable представленовлистинге 11.7.

// Листинг 11.7. Объявление класса synchronization_variable

class synchronization_variable{

protected:

runtime_error Exception;

//.. .

public:

int virtual lock(void) = 0;

int virtual unlock(void) = 0;

int virtual trylock(void) = 0;

//.. .

}

Обратите внимание на то, что методы синхронизации класса synchronization_variable объявлены виртуальными и инициализированы значением 0. Это означает, что они являются чисто виртуальными методами, что делает класс synchronization_variable абстрактным. Из класса, который содержит одну или несколько чисто виртуальных функций, объект прямым путем создать нельзя. Чтобы использовать этот класс, необходимо вывести из него новый класс и определить в нем все чисто виртуальные функции. Абстрактный класс — это своего рода трафарет с указанием того, какие функции должны быть определены в производном классе. Он предлагает интерфейсный проект для производных классов. Он отнюдь не диктует, как нужно реализовать методы, он лишь отмечает, какие методы должны быть представлены в выведенном классе, причем они не могут оставаться в нем чисто виргуальными. С помощью имен этих методов мы можем подсказать предполагаемое их поведение. Таким образом, проектный интерфейсный класс предлагает проект без реализации. Класс этого типа используется в качестве фундамента для будущих классов. Проектный класс гарантирует, что интерфейс будет иметь определенный вид [9]. Класс synchronization_variable обеспечивает интерфейсный трафарет для ceмейства переменных синхронизации. Для обеспечения различных вариантов реализации интерфейса мы используем наследование. Pthread-мьютекс — прекрасный кандидат для интерфейсного класса, поэтому мы определяем класс mutex как производный от класса synchronization_variable.

// Листинг 11.8. Объявление класса мьютекс, который

// наследует класс synchronization_variable

class mutex : public synchronization_variable {

protected:

pthread_mutex_t *Mutex;

pthread_mutexattr_t *MutexAttr;

//.. .

public:

int lock(void) ;

int unlock(void);

int trylock(void);

//. . .

};

Класс mutex должен обеспечить реализации для всех чисто виртуальных функций. Если эти функции определены, значит, политика, предложеннал абстрактным классом, выдержана. Класс mutex теперь не является абстрактным, поэтому из него и из его потомков можно создавать объекты. Каждый из методов класса mutex заключает в оболочку соответствующую Pthread-функцию. Например, код

int mutex::trylock(void) {

//.. .

return(pthread_mutex_trylock(Mutex); //. . .

}

обеспечивает интерфейс для функции pthread_mutex_trylock(). Интерфейсные варианты функций lock(), unlock() и trylock() упрощают вызовы функций библиотеки Pthread. Наша цель — использовать инкапсуляцию и наследование для определения всего семейства мьютексных классов. Процесс наследования — это процесс специализации. Производный класс включает дополнительные атрибуты или характеристики, которые отличают его от предков. Каждый атрибут или характеристика, добавленная в производный класс, конкретизирует его. Теперь мы, используя наследование, можем спроектировать специализацию класса mutex путем введения понятия мьютексного класса, способного обеспечить чтение и запись. Наш обобщенный класс mutex предназначен для защиты доступа к критическому разделу. Если один поток заблокировал мьютекс, он получает доступ к критическому разделу, защищаемому этим мьютексом. Иногда такая мера предосторожности оказывается излишне суровой. Возможны ситуации, когда вполне можно разрешить доступ нескольких потоков к одним и тем же данным, если ни один из этих потоков не модифицирует данные. Другими словами, в некоторых случаях мы можем ослабить блокировку критического раздела и «намертво» запирать его только для действий, которые стремятся модифицировать данные, разрешал при этом доступ для действий, которые предполагают лишь считывание или копирование данных. Такой вид блокировки называется блокировкой считывания (read lock). Блокировка считывания позволяет параллельный доступ к критическому разделу для чтения данных. Критический раздел может быть уже заблокированным одним потоком, но другой поток также может получить блокировку, если у него нет намерения изменять данные. Критический раздел может быть заблокирован для записи одним потоком, а другой поток может запросить блокировку для чтения этого критического раздела.

Архитектура «классной доски» служит прекрасным примером структуры, которая может использовать преимущества «мьютексов считывания» и мьютексов более общего назначения. Под «классной доской» понимается область памяти, разделяемал параллельно выполняемыми задачами. «Классная доска» используется для хранения решений некоторой проблемы, которую совместными усилиями решает целая группа задач. По мере приближения задач к решению проблемы каждая из них записывает результаты на «классную доску» и просматривает ее содержимое с целью поиска результатов, сгенерированных другими задачами, которые могут оказаться полезными для нее. Структура «классной доски» является критическим разделом. В действительности мы хотим, чтобы одновременно только одна задача могла обновлять содержимое «классной доски». Однако ее одновременное считывание мы можем позволить любому количеству задач. Кроме того, если несколько задач уже считывает содержимое «классной доски», нам нужно, чтобы оно не начало обновляться до тех пор, пока все эти задачи не завершат чтение. «Мьютекс считывания» как раз подходит для такой ситуации, поскольку он может управлять доступом к «классной доске», разрешал его только считывающим задачам и запрещал его для записывающих задач. Но если решение проблемы будет найдено, содержимое «классной доски» необходимо обновить. В процессе обновления нам нужно, чтобы ни одна считывающал задача не получила доступ к критическому разделу. Мы хотим заблокировать доступ для чтения до тех пор, пока не завершит обновление записывающал задача. Следовательно, нам нужно создать «мьютекс записи». В любой момент времени удерживать этот «мьютекс записи» может только одна задача. Поэтому мы делаем различие между мьютексом, который блокируется для считывания, но не для записи, и мьютексом, который блокируется для записи, но не для считывания. С использованием мьютекса считывания у нас может быть несколько параллельных считывающих задач, а с использованием мьютекса записи — только одна записывающал задача. Описаннал схема является частью модели CREW (Concurrent Read Exclusive Write — параллельное чтение, монопольнал запись) параллельного программирования.

Для разработки спецификации нашего мьютексного класса нам нужно наделить его способностью выполнять блокировки считывания и блокировки записи. В библиотеке Pthreads предусмотрены мьютексные переменные блокировки чтения-записи и атрибутов:

pthread_rwlock_t и pthread_rwlockattr_t

Эти переменные используются совместно с 11ю pthread_rwlock()-функциями. Мы используем наш интерфейсный класс rw_mutex для инкапсуляции переменных pthread_rwlock_t и pthread_rwlockattr_t, а также для заключения в оболочку Pthread-функций мьютексной организации чтения-записи.

Синопсис

#include <ptrhead.h>

int pthread_rwlock_init(pthread_rwlock_t *,const pthread_rwlockattr_t *);

int pthread_rwlock_destroy(pthread_rwlock_t *) ;

int pthread_rwlock_rdlock(pthread_rwlock_t *);

int pthread_rwlock_tryrdlock(pthread_rwlock_t *);

int pthread_rwlock_wrlock(pthread_rwlock_t *);

int pthread_rwlock_trywrlock(pthread_rwlock_t *);

int pthread_rwlock_unlock(pthread_rwlock_t *);

int pthread_rwlockattr_init(pthread_rwlockattr_t *);

int pthread_rwlockattr_destroy(pthread_rwlockattr_t *);

int pthread_rwlockattr_getpshared(const pthread_rwlockattr_t *,int *);

int pthread_rwlockattr_setpshared(pthread_rwlockattr_t *, int) ;

// Листинг 11.9. Объявление класса rw_mutex, который

// содержит объекты типа pthread_rwlock_ t

// и pthread_rwlockattr_t

class rw_mutex : public mutex{

protected:

struct pthread_rwlock_t *RwLock;

struct pthread_rwlockattr_t *RwLockAttr;

public:

//.. .

int read_lock(void);

int write_lock(void);

int try_readlock(void);

int try_writelock(void);

//.. .

};

Класс rw_mutex наслелует класс mutex. На рис. 11.3 показаны отношения между классами rw_mutex, mutex, synchronization_variable и runtime_error.

Рис. 11.3. Отношения между классами rw_mutex, mutex, synchronization_variable и runtime_error

Пока мы создаем «узкий» интерфейс. На данном этапе мы заинтересованы в обеспечении минимального набора атрибутов и характеристик, необходимых для обобщения нашего класса mutex с использованием мьютексных типов и функций из библиотеки Pthread. Но после создания «узкого» интерфейса для класса mutex мы воспользуемся им как основой для создания «полуширокого» интерфейса. «Узкий» интерфейс обычно применяется в отношении классов, которые связаны наследованием. «Широкие» интерфейсы, как правило, применяют к классам, которые связаны функциями, а не наследованием. Нам нужен интерфейсный класс для упрощения работы с классами или функциями, которые принадлежат различным библиотекам, но выполняют подобные действия. Интерфейсный класс должен обеспечить программиста удобными рабочими инструментами. Для этого мы берем все библиотеки или классы с подобными функциями, отбираем все общие функции и переменные и после некоторого обобщения помещаем их в большой класс, который содержит все требуемые функции и атрибуты. Так определяется класс с «широким» интерфейсом. Но если включить в него (например, в класс rw_mutex) только интересующие нас функции и данные, мы получим «полуширокий» интерфейс. Его преимущества перед «широким» интерфейсом заключаются в том, что он позволяет нам получать доступ к объектам, которые связаны лишь функционально, и ограничивает множество методов, которыми может пользоваться программист, теми, которые содержатся в интерфейсном классе с узким «силуэтом». Это может быть очень важно при интеграции таких больших библиотек функций, как MPI и PVM с POSIX-возможностями параллелизма. Объединение MPI-, PVM- и POSIX-средств дает сотни функций с аналогичными целями. Затратив время на упрощение этой функциональности в интерфейсных классах, вы позволите программисту понизить уровень сложности, связанный с параллельным и распределенным программированием. Кроме того, эти интерфейсные классы становятся компонентами, которые можно многократно использовать в различных приложениях.

Чтобы понять, как подойти к созданию «полуширокого» интерфейса, построим интерфейсный класс для POSIX-семафора. И хотя семафор не является частью библиотеки Pthread, он находит аналогичные применения в многопоточной среде. Его можно использовать в среде, которая включает параллельно выполняемые процессы и потоки. Поэтому в некоторых случалх требуется объект синхронизации более общего характера, чем наш класс mutex.

Определение класса semaphore показано в листинге 11.10.

// Листинг 11.10. Объявление класса semaphore

class semaphore : public synchronization_variable( protected:

sem_t * Semaphore; public://.. .

int lock(void);

int unlock(void);

int trylock(void);

//. . .

};

Синопсис

<semaphore.h>

int sem_init(sem_t *, int, unsigned int) ;

int sem_destroy(sem_t *);

sem_t *sem_open(const char *, int, ...);

int sem_close(sem_t *);

int sem_unlink(const char *);

int sem_wait(sem_t *);

int sem_trywait(sem_t *);

int sem_post(sem_t *);

int sem_getvalue(sem__t *, int *);

Обратите внимание на то, что класс semaphore имеет такой же интерфейс, как и наш класс mutex. Чем же они различаются? Хотя интерфейсы классов mutex и semaphore одинаковы, реализация функций lock (), unlock (), trylock () и тому подобных представляет собой вызовы семафорных функций библиотеки POSIX .

// Листинг 11.11. Определение методов lock(), unlock() и

// trylock() для класса semaphore

int semaphore::lock(void) (

//.. .

return(sem_wait(Semaphore));

}

int semaphore::unlock(void) {

//. . .

return(sem_post(Semaphore));

}

Итак, теперь функции lock (), unlock (), trylock () и тому подобные заключают в оболочку семафорные функции библиотеки POSIX, а не функции библиотеки Pthread. Важно отметить, что семафор и мьютекс — не одно и то же. Но их можно использовать в аналогичных ситуациях. Зачастую с точки зрения инструкций, которые реализуют параллелизм, механизмы функций lock() и unlock() имеют одно и то же назначение. Некоторые основные различия между мьютексом и семафором указаны в табл. 11.2.

Таблица 11.2. Ос н овные различия между мью т ексами и семафорами

• Характеристики мьютексов  

• Мьютексы и переменные условий разделяются между потоками

• Мьютекс деблокируется теми же потоками, которые его заблокировали

• Мьютекс либо блокируется, либо деблокируется

• Характеристики семафоров

•  Семафоры обычно разделяются между процессами, но их разделение возможно и между потоками

• - Освобождать семафор должен необязательно тот процесс или поток, который его удерживал

•  Семафоры управляются количеством ссылок. Стандарт POSIX включает именованные семафоры

Несмотря на важность различий в семантике (см. табл. 11.2), часто их оказывается недостаточно для оправдания применения к семафорам и мьютексам совершенно различных интерфейсов. Поэтому мы оставляем «полуширокий» интерфейс для функций lock(), unlock() и trylock() с одним предостережением: программист должен знать различия между мьютексом и семафором. Это можно сравнить с ситуацией, которая возникает с такими «широкими» интерфейса м и таких контейнерных классов, как deque, queue, set, multiset и пр. Эти контейнерные классы связаны общим интерфейсом, но их семантика в определенных областях различна. Используя понятие интерфейсного класса, можно разработать соответствующие компоненты синхронизации для мьютексов, переменных условий, мьютексов чтения-записи и семафоров. Имея такие компоненты, мы можем спроектировать безопасные (с точки зрения параллелизма) контейнерные, доменные и каркасные классы. Мы можем также применять интерфейсные классы для обеспечения единого интерфейса с различными версиями одной и той же библиотеки функций при необходимости использования обеих версий (по разным причинам) в одном и том же приложении. Иногда интерфейсный класс может быть успешно применен для безболезненного перехода от устарелых функций к новым. Если мы хотим оградить программиста от различий, существующих между операционными системами, то наша цель — обеспечить его соответствующим АРI-интерфейсом [18], независимо от того, какая библиотека семафорных функций используется в среде: System V или POSIX.

Помимо использования интерфейсных классов для упрощения программирования и создания новых «широких» интерфейсов библиотек средств параллелизма и передачи сообщений, имеет смысл также расширить существующие интерфейсы. Например, объектно-ориентированное представление потоков данных можно расширить за счет использования каналов, FIFO-очередей и таких библиотек передачи сообщений, как PVM и MPI. Эти компоненты используются ради достижения межпроцессного взаимодействия (Inter-Process Communication — IPC), межпотокового взаимодействия (Inter-Thread Communication — ITC), а в некоторых случалх и взаимодействия между объектами (Object-to-Object Communicaton — OTOC). Если взаимодействие имеет место между параллельно выполняемыми потоками или процессами, то канал связи может представлять собой критический раздел. Другими словами, если несколько процессов (потоков) попытаются одновременно обновить один и тот же канал, FIFO-очередь или буфер сообщений, непременно возникнет «гонка» данных. Если мы собираемся расширить объектно-ориентированный интерфейс потоков данных за счет включения компонентов из библиотеки PVM или MPI, нам нужно быть уверенными в том, что доступ к этим потокам данных будет безопасен с точки зрения параллелизма. Именно здесь могут пригодиться наши компоненты синхронизации, спроектированные в виде интерфейсных классов. Рассмотрим простой класс pvm_stream.

// Листинг 11.12. Объявление класса pvm_stream, который

// наследует класс mios

class pvm_stream : public mios{

protected:

int TaskId;

int MessageId;

mutex Mutex;

//...

public:

void taskId(int Tid);

void messageId(int Mid);

pvm_stream(int Coding=PvmDataDefault);

void reset(int Coding = PvmDataDefault);

pvm_stream &operator<<(string &Data);

pvm_stream &operator>>(string &Data);

pvm_stream &operator>>(int &Data);

pvm_stream &operator<<(int &Data);

//. . .

};

Этот класс обработки потоков данных предназначен для инкапсуляции состояния активного буфера в PVM-задаче. Операторы вставки "<<" и извлечения ">>" можно использовать для отправки и приема сообщений между PVM-процессами. Здесь мы рассмотрим использование этих операторов только для обработки строк и значений типа int. Интерфейс этого класса далек от совершенства. Поскольку этот класс предназначен для обработки данных любого типа, мы должны расширить определения операторов "<<" и ">>". А так как мы планируем использовать класс pvm_stream в многопоточной программе, мы должны быть уверены в том, что объект класса pvm_stream безопасен для потоков. Поэтому мы включаем в качестве члена нашего класса pvm_stream класс mutex. Поскольку сообщение может быть направлено для конкретной PVM-задачи, класс pvm_stream инкапсулирует для нее активный буфер. Наша цель — использовать классы ostream и istream в качестве «путеводителя» по функциям, которые должен иметь класс pvm_stream. Вспомним, что классы ostream и istream являются классами трансляции. Они переводят типы данных в обобщенные потоки байтов при выводе и обобщенные потоки байтов в конкретные типы данных при вводе. Используя классы istream и ostream, программисту не нужно погружаться в детали вставки в поток или выделения из потока данных того или иного типа. Мы хотим, чтобы и поведение класса pvm_stream было аналогичным. Библиотека PVM располагает различными функциями для каждого типа данных, которые необходимо упаковать в буфер отправки или распаковать из буфера приема. Например, функции pvm_pkdouble () pvm_pkint () pvm_pkfloat() используются для упаковки double-, int- и float-значений соответственно. Аналогичные функции существуют и для других типов данных, определенных в С++. Мы бы хотели поддерживать наше потоковое представление, т.е. чтобы ввод и вывод данных можно было представить как обобщенный поток байтов, который перемещается в программу или из нее. Следовательно, мы должны определить операторы вставки (<<) и извлечения (>>) для каждого типа данных, который мы собираемся использовать при обмене сообщениями между PVM-задачами. Мы также моделируем состояние потока данных в соответствии с классами istream и ostream, которые содержат компонент ios, предназначенный для хранения состояния этого потока. Поток данных может находиться в состоянии ошибки либо в одном из различных состояний, которые выражаются восьмеричным, десятичным или шестнадцатеричным числом. Поток также может пребывать в нормальном, заблокированном или состоянии конца файла. Класс pvm_stream должен не только содержать компонент, который поддерживает состояние потока данных, но и методы, которые устанавливают заданное или исходное состояние PVM-задачи, а также считывают его. Наш класс pvm_stream для этих целей содержит компонент mios. Этот компонент поддерживает состояние потока данных и активного буфера отправки и приема информации. На рис. 11.4 представлены две диаграммы классов: одна отображает отношения между основными классами библиотеки iostream, а вторая — отношения между классом pvm_stream и ero компонентами.

Обратите внимание на то, что классы istream и ostream наследуют класс ios . Класс ios поддерживает состояние потока данных и состояние буфера, используемого классами istream и ostream. Наш класс mios исполняет ту же роль в отношении класса pvm_stream. Классы istream и ostream содержат определения операторов "<<" и ">>". Эти же операторы определены и в нашем классе pvm_stream. Поэтому, хотя наш класс pvm_stream не связан с iostream-классами наследованием, между ними существует интерфейсная связь. Мы используем интерфейс iostream-классов в качестве «полуширокого» интерфейса для классов pvm_stream и mios. Обратите внимание на то, что класс mios (см. рис. 11.4) наслелуется классом pvm_stream. Если мы хотим поддерживать потоковое представление с помощью класса pvm_stream, то для этого как раз подходит понятие интерфейсного класса.

Рис. 11.4. Диаграмма классов, отображающая отношения между основными классами библиотеки iostream, и диаграмма класса pvm_stream

Итак, рассмотрим определение операторов "«" и ">>" для класса pvm__stream. Оператор вставки (<<) используется для заключения в оболочку функций pvm_send () и pvm_pk. Вот как выглядит определение этого операторного метода.

// Листинг 11.13. Определение оператора "<<" для класса

// pvm_stream class

pvm_stream &pvm_stream::operator<<(int Data) {

//...

reset();

pvm_pkint(&Data,1,1); pvm_send(TaskId,MessageId); //.. .

return(*this);

}

Подобное определение существует для каждого типа данных, которые будут обрабатываться с использованием класса pvm_stream. Метод reset () унаследован от класса mios. Этот метод используется для инициализации буфера отправки д анных. TaskId и MessageId — это члены данных класса pvm_stream, которые устанавливаются с помо щ ью мето д ов taskId( ) и messageId( ). Определяемый здесь оператор вставки позволяет отправлять данные PVM-задаче с помощью стандартной записи операции вывода в поток.

int Value = 2004;

pvm_stream MyStream;

//...

MyStream << Value;

//.. .

Оператор извлечения данных (>>) используется подобным образом, но для получения сообщений от PVM-задач. В действительности оператор ">>" заключает в оболочку функции pvm_recv () и pvmupk (). Определение этого операторного м етода выглядит так.

//

Листинг 11.14. Определение оператора для класса

// pvm_stream

pvm_stream &pvm_stream::operator>>(int &Data) {

int BufId;

//. . .

BufId = pvm_recv(TaskId,MessageId);

StreamState = pvm_upkint(&Data,l,l); //.. .

return(*this);

}

Этот тип определения позволяет получать сообщения от PVM-задач с помощью оператора извлечения данных.

int Value;

pvm_stream MyStream;

MyStream >> Value;

Поскольку каждый из рассмотренных операторных методов возвращает ссылку на тип pvm_stream , операторы вставки и извлечения можно соединить в цепочку.

Mystream << Valuel << Value2;

Mystream >> Value3 >> Value4;

Используя этот простой синтаксис, программист изолирован от более громоздкого синтаксиса функций pvm_send, pvm_pk, pvm_upk и pvm_recv . При этом он работает с более знакомыми для него объектно-ориентированными потоками данных. В данном случае поток данных представляет буфер сообщений, а элементы, которые помещаются в него или извлекаются оттуда, представляют сообщения, которыми обмениваются между собой PVM-процессы. Вспомните, что каждый PVM-процесс имеет отдельное адресное пространство. Поэтому операторы "<<" и ">>" не только маскируют вызовы функций pvm_send и pvm_recv, они также маскируют заложенную в них организацию связи. Поскольку класс pvm_stream можно использовать в много-поточной среде, операторы вставки и извлечения данных должны обеспечивать безопасность потоков выполнения.

Класс pvm_stream (см. рис. 11.4) содержит класс mutex. Класс mutex можно использовать для защиты критических разделов, которые имеются в классе pvm_stream. Класс pvm_stream инкапсулирует доступ к буферу отправки и буферу приема данных. Взаимодействие потоков выполнения и класса pvm_stream с буферами pvm_send и pvm_receive показано на рис. 11.5.

Рис.11.5. Взаимодействие потоков выполнения и класса pvm_stream с буферами pvm_send и pvm_receive

Критическими разделами являются не только буферы отправки и приема данных. Класс mios, используемый для хранения состояния класса pvm_stream, также является критическим разделом. Для защиты этого компонента можно использовать класс mutex.

При обращении к операторам вставки и извлечения данных можно использовать объект Mutex.

// Листинг 11.15.

//Определение операторов «<<» и «>>» для класса pvm_stream

pvm_stream &pvm_stream::operator<<(int Data) {

//.. .

Mutex.lock(); reset();

pvm_pkint(&Data,1,1); pvm_send(TaskId,MessageId); Mutex.unlock(); //.. .

return(*this);

}

pvm_stream &pvm_stream::operator>>(int &Data) {

int BufId; //. . .

Mutex.lock();

BufId = pvm_recv(TaskId,MessageId);

StreamState = pvm_upkint(&Data,1,1);

Mutex.unlock();

//. . .

return(*this);

}

Этот вид защиты позволяет сделать класс pvm_stream безопасным. Здесь мы не представили код обработки исключений или другой код, который бы позволил предотвратить бесконечные отсрочки или взаимную блокировку. Основнал идея в данном случае — сделать акцент на компонентах и вариантах архитектуры, которые пригодны для поддержки параллелизма. Интерфейсный класс mutex и класс pvm_stream можно использовать многократно, и оба они поддерживают параллельное программирование. Предполагается, что объекты класса pvm_stream должны использоваться PVM-задачами при отправке и приеме сообщений. Но это не является жестким требованием. Для того чтобы пользователь мог применить концепцию класса pvm_stream к своим классам, для них необходимо определить операторы вставки (<<) и извлечения (>>).

Чтобы понять, как определенный пользователем класс можно использовать совместно с классом pvm_stream, попробуем усовершенствовать возможности PVM-палитры, представленной в главе 6. Класс палитры представляет простую коллекцию цветов. Для удобства будем сохранять цвета в векторе строк (vector<string>) с именем Colors.

Начне м с объявления класса spectral_palette, который содержит friend- объявления дл я операторов вставки (<<) и извлечени я (>>).

// Листинг 11.16. Объявление класса spectral_palette

class spectral_palette : public pvm_object{

protected:

//. . .

vector<string> Colors;

public:

spectral_palette(void);

//...

friend pvm_stream &operator>>(pvm_stream &In,spectral_palette &Obj);

friend pvm_stream &operator<<(pvm_stream &Out,spectral_palette &Obj);

//. . .

Обратите внимание на то, что класс spectral_palette в листинге 11.16 наследует класс pvm_object. Класс pvm_object тем самым обеспечивает своего наследника доступом к идентификатору задачи и идентификатору сообщения. Вспомните, что идентификаторы задачи и сообщения используются во многих PVM-функциях. С помощью определения операторов вставки (<<) и извлечения (>>) объекты класса spectral_palette можно пересылать между параллельно выполняемыми PVM-задачами. Метод, используемый для класса spectral_palette, очень прост, и его можно так же успешно применить к любому пользовательскому классу. Поскольку класс pvm_stream должен иметь эти операторы для встроенных типов данных и контейнеров, которые содержат значения встроенных типов данных, в пользовательском классе необходимо определить только операторы "<<" и ">>" для перевода их представления в любой встроенный тип данных или стандартный контейнер. Вот как, например, определяется оператор "<<" для класса spectral_palette в листинге 11.17.

// Листинг 11.17. Определение оператора для

// класса spectral_palette

pvm_stream &operator<<(pvm_stream &Out, spectral_palette &Obj)

{

int N;

string Source;

for(N = 0;N < Obj.Colors.size();N++) {

Source.append(Obj.Colors[N]);

if( N <Obj.Colors.size() - 1){

Source.append(" ");

}

}

Out.reset();

Out.taskId(Obj.TaskId);

Out.messageId(Obj.MessageId);

Out << Source;

return(Out);

}

Рассмотрим подробнее определение этой операции вставки в листинге 11.17. Поскольку класс pvm_stream работает только со встроенными типами данных, цель пользовательского оператора "<<" — перевести пользовательский объект в последовательность значений встроенных типов данных. Этот перевод является одной из основных обязанностей классов, «отвечающих» за потоковое представление данных. В данном случае объект класса spectral_palette должен быть переведен в строку «цветов», разделенных пробелами. Список цветовых значений сохраняется в строке Source. Рассматриваемый процесс перевода позволяет применить к объекту этого класса оператор "<<", который был определен для строкового типа данных. Имея определения этих операторов, API-интерфейс программиста становится более удобным, чем при использовании ори г инальных версий функций библиотеки Pthread, POSIX и MPI. Ведь теперь объект класса spectral_palette можно переслать из одной PVM-задачи в другую, используя такую привычную операцию вставки (<<).

// Листинг 11.18. Использование объектов классов

// pvm_stream и spectral_palette

pvm_stream TaskStream;

spectral_palette MyColors;

//. . .

TaskStream.taskId(20001);

TaskStream.messageId(l); //.. .

TaskStream « MyColors; //.. .

Здесь объект MyColors пересылается в соответствующую PVM-задачу. На рис. 11.6 показаны компоненты, используемые для поддержки объектов TaskStream и MyColors. Каждый компонент на рис. 11.6 можно детализировать и оптимизировать в отдельности. Каждый представленный здесь уровень обеспечивает дополнительный слой изоляции от сложности этих компонентов. В идеале на самом высоком уровне программист должен заниматься только деталями, связанными с данной предметной областью. Такой высокий уровень абстракции позволяет программисту самым естественным образом представлять параллелизм, который вытекает из требований предметной области, не углубляясь при этом в синтаксис и сложные последовательности вызовов функций. Компоненты, представленные на рис. 11.6, следует рассматривать лишь как малую толику библиотеки классов, которую можно использовать для PVM-программ и многопоточных PVM-программ. Те же методы можно применять для взаимодействия между параллельно выполняемыми задачами, которые не являются частью PVM-среды. Ведь существует множество приложений, которые требуют реализации параллельности, но не нуждаются во всей полноте функционирования механизма PVM-cреды. Для таких приложений вполне достаточно использования функций ехес( ), fork () или pvm_spawn (). Примерами таких приложений могут служить программы, которые требуют создания нескольких параллельно выполняемых процессов, и приложения типа «клиент-сервер». Для таких нePVM - или неМРI-приложений также может потребоваться организация межпроцессного взаимодействия. Для параллельно выполняемых процессов, создаваемых посредством fork-exec- последовательности вызовов или функций pvm_spawn, имело бы смысл поддерживать потоковое представление данных. Понятие объектно-ориентированного потока данных можно также расширить с помощью каналов и FIFO-очередей.

Рис.11.6. Компоненты, используемые для поддержки объектов TaskStream и MyColors

Приступая к разработке объектноориентированных каналов, начнем с рассмотрения базовых характеристик и поведения каналов в целом. Канал представляет собой средство взаимодействия между несколькими процессами. Для того чтобы процессы могли взаимодействовать, необходимо обеспечить между ними передачу информации определенного вида. Эта информация может представлять данные или команды, предназначенные для выполнения. Обычно такая информация преобразуется в последовательность данных и помещается в канал, а затем считывается процессом с другого конца канала. При считывании из канала данные снова преобразуются, чтобы обрести смысл для считывающего процесса. В любом случае при передаче от одного процесса другому эти данные должны где-то храниться. Мы называем область хранения информации буфером данных. Для размещения данных в этом буфере и извлечения их оттуда необходимо выполнять соответствующие операции. Но прежде чем говорить о выполнении таких операций, необходимо позаботиться о существовании самого буфера данных. Объектно-ориентированный канал должен обладать средствами, которые поддерживают операции создания и инициализации буфера данных. После завершения взаимодействия между процессами буфер данных, используемый для хранения информации, становится ненужным. Это означает, что наш объектно-ориентированный канал должен «уметь» удалять буфер данных после его использования. Из этого «введения в каналы» вырисовываются по крайней мере пять основных компонентов, которыми должен обладать объектно-ориентированный канал:

• буфер;

• операция вставки данных в буфер;

• операция извлечения данных из буфера;

• операция создания/инициализации буфера;

• операция ликвидации буфера.

Помимо этих пяти базовых компонентов, канал должен иметь два конца. Один конец предназначен для вставки данных, а другой — для их извлечения. К этим двум концам могут получать доступ различные процессы. Чтобы наше описание канала было полным, мы должны включить в него порт ввода и порт вывода, к которым могут подключаться различные процессы. В результате мы получаем уже семь базовых компонентов, составляющих описание нашего объектно-ориентированного канала:

• порт ввода;

• порт вывода;

• буфер;

• операция вставки данных в буфер;

• операция извлечения данных из буфера;

• операция соз д ания/инициализации буфера;

• операция ликви д ации буфера.

Эти компоненты образуют минимальный набор характеристик, составляющих описание канала. Уточнив базовые компоненты, можно поразмыслить о том, как при разработке объектно-ориентированного канала лучше всего использовать существующие системные API-интерфейсы или структуры данных. В разработке каналов попробуем для начала применить те же методы (инкапсуляцию и перегрузку операторов), которые мы использовали при разработке класса pvm_stream.

Обратите внимание на то, что пять из семи выше перечисленных базовых компонентов являются общими лля многих основных структур данных и типов контейнеров, которые обычно используются для операций ввода-вывода. В большинстве случаев UNDC/Linux-средства работы с файлами поддерживают:

• буферы;

• операции вставки данных в буфер;

• операции извлечения данных из буфера;

• операции создания буфера;

• операции удаления буфера.

Для инкапсуляции функций, предоставляемых системными UNIX/Linux-службами, мы используем понятие интерфейсных С++-классов и создаем объектно-ориентированные версии сервисных функций ввода-вывода. Если в случае с классом pvm_stream для библиотеки PVM нам приходилось начинать «с нуля», то здесь мы можем воспользоваться преимуществами существующей стандартной библиотеки С++ и библиотеки классов iostreams. Вспомните, что библиотека классов iostreams поддерживает объектно-ориентированную модель потоков ввода и вывода. Более того, эта объектно-ориентированнал библиотека оснащена поддержкой буферизации данных и всех операций, связанных с использованием буфера. На рис. 11.7 показана простая диаграмма класса basic_iostream.

Рис. 11.7. Диаграмма классов, отображающая основные компоненты класса basic_iostream

Основные компоненты класса basic_iostream можно описать тремя видами классов: компонент буфера, компонент преобразования и компонент состояния [23]. Компонент буфера используется в качестве области промежуточного хранения байтов информации. Компонент преобразования отвечает за перевод анонимных последовательностей байтов в значения и структуры данных соответствующих типов, а также за перевод структур данных и отдельных значений в анонимные последовательности байтов. Компонент преобразования отвечает за обеспечение программиста потоковым представлением байтов, в котором все операции ввода-вывода независимо от источника и приемника обрабатываются как поток байтов. Компонент состояния инкапсулирует состояние объектно-ориентированного потока и позволяет определить, какой тип форматирования применим к байтам данных, которые содержатся в компоненте буфера. Компонент состояния также содержит информацию отом, в каком режиме был открыт поток: дозаписи, создания, монопольного чтения, монопольной записи, а также о том, будут ли числа интерпретироваться как шестна-дцатеричные, восьмеричные или двоичные. Компонент состояния также можно использовать для определения состояния ошибки операций ввода-вывода, выполняемых над компонентом буфера. Опросив этот компонент, программист может определить, в каком состоянии находится буфер, условно говоря, в хорошем или плохом. Эти три компонента представляют собой объекты, которые можно использовать совместно (для формирования полнофункционального объектноориентированного потока) или в отдельности (в качестве вспомогательных объектов в других задачах).

Пять из семи базовых компонентов нашего потока уже реализованы в библиотеке классов iostreams. Поэтому нам остается лишь дополнить их компонентами портов ввода и вывода. Для этого мы можем рассмотреть системные средства поддержки потоков. В среде UNIX/Linux создать канал можно с помощью вызовов системных функций (листинг 11.19).

// Листинг 11.19. Использование системного вызова для

// создания канала

int main(int argc, char *argv[]) {

//.. .

int Fd[2];

pipe(Fd);

//.. .

}

Функция pipe () предназначена для создания структуры данных канала, которую можно использовать для взаимодействия между родительским и сыновним процессами. При успешном обращении к функции pipe () она возвращает два дескриптора файла. (Дескрипторы файлов представляют собой целые значения, которые используются для идентификации успешно открытых файлов.) В этом случае дескрипторы сохраняются в массиве Fd. Элемент Fd[0] используется при открытии файла для чтения, а элемент Fd[1] — при открытии файла для записи. После создания эти два дескриптора файлов можно использовать при вызове функций read() и write(). Функция write() обеспечивает вставку данных в канал посредством дескриптора Fd[1], а функция read() — извлечение данных из канала посредством дескриптора Fd[0]. Поскольку функция pipe () возвращает дескрипторы файлов, доступ к каналу можно получить с помощью системных средств работы с файлами. Для определения максимально возможного количества доступных дескрипторов файлов, открытых одним процессом, можно использовать системную функцию sysconf(_SC_OPEN_MAX), адля определения размера канала — функцию pathconf(_PC_PIPE_BUF).

Эти два файловых дескриптора представляют наши логические порты ввода и вывода соответственно. Мы также используем их для связи с библиотекой классов iostreams. В частности, они обеспечивают связь с классом буфера. Ко м понент буфера iostreams-классов имеет три семейства классов. Эти три типа буферных классов перечислены в табл. 11.3.

Таблица 11.3. Три типа буферных классов

basic_streambuf Описывает поведение различных потоковых буферов с целью управления входными и выходными последовательностями символов

basic_stringbuf Связывает входные и выходные последовательности с последовательностью произвольных символов, которая может быть использо-ванадля инициализации или доступна в качестве строкового объекта

basic_filebuf Связывает входные и выходные последовательности символов с файлом

Рассмотрим подробнее класс basic_filebuf. Тогда как класс basic_streambuf используется в качестве объектно-ориентированного буфера в операциях ввода-вывода с применением стандартного потока, а класс basic_stringbuf — в качестве объектно-ориентированного буфера для памяти, класс basic_filebuf применяется в качестве объектно-ориентированного буфера для файлов. Рассмотрев интерфейс для класса basic_filebuf и интерфейс для классов преобразования (basic_ifstream, basic_ofstream и basic_fstream), можно найти способ связать дескрипторы файлов, возвращаемые системной функцией pipe (), с объектами класса basic_iostream. На рис. 11.8 показаны диаграммы классов для семейства fstream-классов.

Рис. 11.8. Диаграммы классов для семейства fstream-классов

Обратите вни м ание на то, что все классы basic_ifstream, basic_ofstream и basic_fstream содержат класс basic_filebuf. Следовательно, чтобы упростить создание объектно-ориентированного канала, мы можем использовать любой класс из семейства fstream-классов. Мы можем связать дескрипторы файлов, возвращаемые системной функцией pipe() , либо с помощью конструкторов, либо с помощью функции-члена attach() .

Синопсис

#include <fstream>

// UNIX-системы

ifstream(int fd)

fstream(int fd)

ofstream(int fd)

// gnu C++

void attach(int fd) ;

Существует три iostream-класса (ifstream, ofstream и fstream), которые мы можем использовать для подключения к каналу. Объект класса ifstream используется для ввода данных, объект класса ofstream — для их вывода, а объект класса fstream можно применять и в том и в другом случае. Несмотря на то что непосредственная поддержка дескрипторов файлов и потоков ввода-вывода не является частью стандарта ISO, в большинстве UNIX- и Linux-сред поддерживается С++-ориентированный iostream-доступ к дескрипторам файлов. В библиотеке GNU С++ iostreams предусмотрена поддержка дескриптора файла в одном из конструкторов классов ifstream, ofstream и fstream и в методе attach( ) , определенном в классах ifstream и ofstream. UNIX-компилятор языка С++ ко м пании Sun также поддерживает дескрипторы файлов с помощью одного из конструкторов классов ifstream, ofstream и fstream. Поэтому при выполнении следующего фрагмента кода

//...

int Fd[2];

Pipe(Fd);

ifstream IPipe(Fd[0]) ;

ofstream OPipe(Fd[1]) ;

будут созданы объектно-ориентированные каналы. Объект IPipe будет играть роль входного потока, а объект OPipe— выходного. После создания эти потоки можно применять для связи между параллельно выполняемыми процессами с использованием потоково г о представления и операторов вставки (<<) и извлечения (>>). Для С++-сред, которые поддерживают метод attach(), дескриптор файла можно связать с объектами классов ifstream, ofstream или fstream, используя следующий синтаксис.

// Листинг 11.20. Создание канала и использование

// функции attach()

int Fd[2];

ofstream OPipe;

//.. .

pipe(Fd);

//.. .

OPipe.attach(Fd[1]);

//.. .

OPipe << Value << endl;

Такой способ использования объектно-ориентированных каналов предполагает существование сыновнего процесса, который может считывать из них информацию. В программе 11.1 для создания двух процессов используется fork-инструкция. Родительский процесс отправляет значение сыновнему процессу с помощью iostreams-ориентированного канала.

// Программа 11.1

1   #include <unistd.h>

2   #include <iostream.h>

3   #include <fstream.h>

4   #include <math.h>

5   #include <sys/wait.h> 6

7 8 9

10   int main(int argc, char *argv[])

11   {

12

13   int Fd[2];

14   int Pid;

15   float Value;

16   int Status;

17   if(pipe(Fd) != 0) {

18   cerr « «Ошибка при создании канала " « endl;

19   exit(l);

20   }

21   Pid = fork();

22   if(Pid == 0){

23   ifstream IPipe(Fd[0]);

24   IPipe » Value;

25   cout « «От процесса-родителя получено значение» << Value << endl;

26   IPipe.close();

27   }

28   else{

29   ofstream OPipe(Fd[l]);

30   OPipe « M_PI « endl;

31   wait(&Status);

32   OPipe.close();

33

34 }

35

36 }

Вспомните, что значение 0, возвращаемое функцией fork(), принадлежит сыновнему процессу. В программе 11.1 канал создается при выполнении инструкции, расположенной на строке 17. А при выполнении инструкции, расположенной на строке 29, родительский процесс открывает канал для записи. Файловый дескриптор Fd[1] означает «записывающий» конец канала. К этому концу канала (благо д аря вызову конструктора на строке 29) присоединяется объект класса ofstream. К «считывающему» концу канала присоединяется объект класса ifstream (строка 23). Сыновний процесс открывает канал для чтения и получает доступ к дескриптору файла, поскольку он вместе со средой родителя наслелует и дескрипторы файлов. Таким образом, любые файлы, которые открыты в среде родителя, будут оставаться открытыми и в среде наследника, если операционнал система не получит явные инструкции, основанные на системной функции fcntl. Помимо наследования открытых файлов, маркеры внутрифайловых позиций остаются там, где они были в момент порождения сыновнего процесса, чтобы сыновний процесс также получил доступ к маркеру позиции. При изменении позиции в родительском процессе маркер сыновнего также смещается. В этом случае мы могли бы реализовать потоковое представление данных, не создавал интерфейсный класс. Просто присоединив файловые дескрипторы канала к объектам классов ofstream и ifstream, мы сможем использовать операторы вставки (<<) и извлечения (»). Аналогично любой класс, в котором определены операторы ">>" и "<<", может выполнять операции вставки данных в канал и извлечения их оттуда без какого-либо дополнительного программирования. В программе 11.1 родительский процесс поме щ ает значение M_PI в канал (строка 30), а сыновний процесс извлекает это з н ачение из канала, используя оператор ">>" (строка24). Инструкции по выполнению и компиляции этой программы приведены в разделе «Профиль программы 11.1».

f

(Профиль программы 11.1

Имя программы program11-1.cc

Оп и сание

Программа 11.1 демонстрирует использование объектно-ориентированного потока c использованием анонимных системных каналов. Для создания двух процессов, |которые взаимодействуют между собой с помощью операторов вставки («) и из-!влечения (»), программа использует функцию fork().

Требуемые заголовки

<wait.h>,<unistd.h>, <iostream.h>, <fstream.h>, <math.h>.

Инс т рукци и по компиляции и компоновке программ

C++ -о program11-1 program11-1.cc

Среда для т ес ти рова ни я

Solaris 8, SuSE Linux 7.1.

Инструкции по выполнению

./program11-1

Компилятор gnu С++ также под д ерживает метод attach (). Этот мето д можно использовать д ля связи файловых д ескрипторов с объекта м и классов ifstream и ofstream (листинг 11.21).

// Листинг 11.21. Подключение файловых дескрипторов к

// объекту класса ofstream

int main (int argc, char *argv[]) {

int Fd[2];

ofstream Out;

pipe(Fd);

Out.attach(Fd[l]); // - . .

// Межпроцессное взаимодействие. //. . .

Out.close( );

}

При вызове функции Out.attach(Fd[1] ) объект класса ofstream связывается с файловым дескриптором канала. Теперь Любая информация, которая будет помещена в объект Out, в действительности запишется в канал. Использование операторов извлечения и вставки для выполнения автоматического преобразования формата является основным достоинством использования семейства fstream -классов в сочетании с канальной связью. Возможность применять пользовательские средства извлечения и вставки избавляет программиста от определенных трудностей, которые могут иметь место при программировании каналов связи. Поэтому вместо явного перечисления размеров данных, записываемых в канал и читаемых из него, при управлении доступом для чтения-записи мы используем только количество передаваемых через канал элементов, что существенно упрощает весь процесс. К тому же такое «снижение себестоимости» немного упрощает параллельное программирование. Рекоменлуемый нами метод состоит в использовании архитектуры, в основе которой лежит принцип «разделяй и властвуй». Главное — правильно расставить компоненты «по своим местам» — и программирование станет более простым. Например, поскольку канал связывается с объектами классов ofstream и ifstream, мы можем использовать информацию, хранимую компо н ентом ios, для определения состояния канала. Компоненты преобразования iostreams-классов можно использовать для выполнения автоматического преобразования данных, помещаемых в один конец канала и извлекаемых из его другого конца. Использование каналов вместе с iostream-классами также позволяет программисту интегрировать стандартные контейнеры и алгоритмы с использованием межпроцессного взаимодействия на основе канала. На рис. 11.9 показаны взаимоотношения между объектами классов ifstream, ofstream, каналом и средствами вставки и извлечения при организации межпроцессного взаимодействия.

Для чтения данных из канала и записи данных в канал можно также испо л ьзовать семейство к л ассов fstream и функции-ч л ены read () и write ().

Канал можно также испо л ьзовать с итераторами ostream_iterator и istream_ iterator, которые представляют собой обобщенные объектно-ориентированные указатели. Итератор ostream_iterator позволяет передавать через канал целые контейнеры (т.е. списки, векторы, множества, очереди и пр.). Без использования iostreamo6beKTOB и итератора ostream_iterator передача контейнеров объектов была бы очень громоздкой и подверженной ошибкам процедурой. Операции, которые доступны для классов ostream_iterator и istream_iterator, перечислены в табл. 11.4.

Рис.11.9. Взаимоотношения между объектами классов ifstream, ofstream, каналом и средствами вставки и извлечения при организации межпроцессного взаимодействия

Таблица»11.4. Операции, доступныедля классов ostream_iterator и istream_iterator

istream_iterator

а == b отношение эквивалентности

а != b отношение неэквивалентности

*a разыменовывание

++r инкремент (префиксная форма)

r++ инкремент (постфиксная форма)

ostream_iterator

++r инкремент (префиксная форма)

r++ инкремент (постфиксная форма)

Обычно эти итераторы используются вместе с iostreams-классами и стандартными алгоритмами. Итератор ostream_iterator предназначен только для последовательно выполняемой записи. После доступа к некоторому элементу программист не может вернуться к нему опять, не повторив всю итерацию сначала. При использовании этих итераторов канал обрабатывается как последовательный контейнер. Это означает, что при связывании канала с iostreams-объектами посредством итератора ostream_iterator и файловых дескрипторов мы можем применить стандартный алгоритм обработки данных для ввода их из канала и вывода их в канал. Причина того, что эти итераторы можно использовать вместе с каналами, состоит в связи, которая существует между итераторами и iostreams-классами. На рис. 11.10 представлена диаграмма, отображающая отношения между итераторами ввода-вывода и iostreams-классами.

Рис. 11.10. Отношения между итераторами ввода-вывода и iostreams-классами

На рис. 11.10 также показано, как эти классы взаимодействуют с объектно-ориентированным каналом. Рассмотрим подробнее, как итератор ostream_iterator используется с объектом класса ostream. Если инкрементируется указатель, мы ожидаем, что он будет указывать на следующую область памяти. Если же инкрементируется итератор ostream_iterator, он переме щ ается на следующую позицию выходного потока. Присваивал значение разыменованному указателю, мы тем самым помещаем это значение в область, на которую он указывает. Присваивал значение итератору ostream_iterator, мы помещаем это значение в выходной поток. Если выходной поток связан с объектом cout, это значение отобразится на стандартном устройстве вывода. Мы можем объявить объект класса ostream_iterator следующим образом, ostream_iterator<int> X(cout, «\n»);

Тогда X является объектом типа ostream_iterator. При выполнении операции инкремента X++; итератор X перейдет к слелую щ ей позиции выходного потока. А при выполнении этой инструкции присваивания

*X = Y;

значение Y будет отображено на стандартном устройстве вывода. Дело в том, что оператор присваивания "=" перегружен дл я использования объекта класса ostream. В результате объявления

ostream_iterator<int> X(cout, «\n»);

будет создан объект X с использованием аргумента cout. Второй аргумент в конструкторе является разделителем, который автоматически будет размещаться после каждого int -значения, вставляемого в поток данных. Объявление итератора ostream_iterator выглядит следующим образом (листинг 11.22).

// Листинг 11.22. Объявление класса ostream_iterator

template <class _Tp> class ostream_iterator {

protected:

ostream* _M_stream;

const char* _M_string; public:

typedef output_iterator_tag iterator_category;

typedef void value_type;

typedef void difference_type;

typedef void pointer;

typedef void reference;

ostream_iterator(ostream& _s) : _M_stream(&_s),_M_string(0) {}

ostream_iterator(ostream& _s, const char* _с): _M_s tream (&_s) , _M_string (_с) { }

ostream_iterator<_Tp>& operator=(const _Tp& _value) {

*_M_stream << _value;

if (_M_string){

*_M_stream << _M_string;

return *this;

}

ostream_iterator<_Tp>& operator*() { return *this; }

ostream_iterator<_Tp>& operator++() { return *this; }

ostream_iterator<_Tp>& operator++(int) { return *this; }

};

Конструктор класса ostream_iterator принимает ссылку на объект класса ostream. Класс ostream_iterator находится с классом ostream в отношении агрегирования. Назначение класса istream_iterator прямо противоположно классу ostream_iterator. Он используется с объектами класса istream (а не с объектами класса ostream). Если объекты классов istream_iterator и ostream_iterator связаны с iostream-объектами, которые в свою очередь связаны с файловыми дескрипторами канала, то при каждом инкрементировании итератора типа istream_iterator из канала будут считываться данные, а при каждом инкрементировании итератора типа ostream_iterator в канал будут записываться данные. Чтобы продемонстрировать, как эти компоненты работают вместе, рассмотрим две программы (11.2 и 11.2.1), в которых используются анонимные каналы связи. Про-грамма11.2 представляет родительский процесс, а программа11.2.1— сыновний. В»родительской» части для создания сыновнего процесса используются системные функции fork() и execl (). При том, что файловые дескрипторы наследуются сыновним процессом, их значения незамедлительно становятся достоянием программы 11.2.1 благодаря вызовуфункции execl() .

// Программа 11.2

10 int main(int argc, char *argv[])

11 {

12

13 int Size,Pid,Status,Fdl[2],Fd2[2];

14 pipe(Fdl); pipe(Fd2);

15 strstream Buffer;

16 char Value[50];

17 float Data;

18 vector<float>X(5,2.1221), Y;

19 Buffer « Fdl[0] « ends;

20 Buffer » Value;

21 setenv(«Fdin»,Value,l);

22 Buffer.clear();

23 Buffer « Fd2[l] « ends;

24 Buffer » Value;

25 setenv(«Fdout»,Value,l);

26 Pid = fork();

27 if(Pid != 0){

28 ofstream OPipe;

29 OPipe.attach(Fdl[l] ) ,-

30 ostream_iterator<float> OPtr(OPipe,"\n»);

31 OPipe « X.size() « endl;

32 copy(X.begin(),X.end(),OPtr);

33 OPipe « flush;

34 ifstream IPipe;

35 IPipe.attach(Fd2[0]);

36 IPipe » Size;

37 for(int N = 0; N < Size;N++)

38 {

39 IPi ре » Data;

40 Y.push_back(Data);

41 }

42 wait(&Status);

43 ostream_iterator<float> OPtr2(cout,"\n»);

44 copy(Y.begin(),Y.end(),OPtr2);

45 OPipe.close();

46 IPipe.close();

47 }

48 else{

49 execl("./programll-2b»,«programll-2b»,NULL);

50 } 51

52 return(0);

53 }

В строках 21 и 25 системнал функция setenv () используется для передачи значений файловых дескрипторов сыновнему процессу. Это возможно благодаря тому, что сыновний процесс наслелует среду родительского процесса. Мы можем устанавливать переменные среды в программе с помощью вызова функции setenv (). В данном случае мы устанавливаем их следующим образом.

Fdin=filedesc; Fdout=filedesc;

Сыновний процесс затем использует системный вызов getenv( ) для считывания значений переменных Fdin и Fdout. Значение переменной Fdin будет представлять «считывающий конец» канала для сыновнего процесса, а значение переменной Fdout — «записывающий». Использование системных функций setenv () и getenv() обеспечивает просгую форму межпроцессного взаимодействия (interprocess communication — IPC) между родительским и сыновним процессами. Каналы создаются при выполнении инструкций, приведенных в строке 14. Родительский процесс присоединяется к одному концу канала для операции записи с помощью метода attach() (строка29). После присоединения любые данные, помещенные в объект OPipe типа ofstream, будут записаны в канал. Итератор типа ostream_iterator подключается к объекгу OPipe при выполнении следующей инструкции (строка 30):

ostream_iterator<float> OPtr(OPipe,"\n»);

Теперь итератор OPtr ссылается на объект OPipe. После каждой порции помещаемых в канал данных будет вставляться разделитель "\n». С помощью итератора OPtr мы можем поместить в канал любое количество float -значений. При этом мы можем связать с каналом несколько итераторов различных типов. Но в этом случае необходимо, чтобы на «считывающем» конце канала данные извлекались с использованием ите раторов соответствующих типов. При выполнении слелующей инструкции из программы 11.2 в канал сначала помещается количество элементов, подлежащих передаче: OPipe « X.size() « endl;

Сами элементы отправляются с использованием одного из стандартных С++-алгоритмов:

copy(X.begin() ,X.end() ,OPtr) ;

Алгоритм copy () копирует содержимое одного контейнера в контейнер, связанный с итератором приемника. Здесь итератором приемника является объект OPtr. Объект OPtr связан с объектом OPipe, поэтому при выполнении алгоритма copy () («уместившегося» в одной строке кода) в канал переписывается все содержимое контейнера. Этот пример демонстрирует возможность использования стандартных алгоритмов для организации взаимодействия между различными частями сред параллельного или распределенного программирования. В данном случае алгоритм copy () пересылает информацию от одного процесса другому (из одного адресного пространства в другое). Эти процессы выполняются параллельно, и алгоритм copy () значительно упрощает взаимодействие между ними. Мы подчеркиваем важность этого подхода, поскольку, если есть хоть какал-то возможность упростить логику параллельной или распределенной программы, ею нужно непременно воспользоваться. Ведь межпроцессное взаимодействие — это один из самых сложных разделов параллельного или распределенного программирования. С++-алгоритмы, библиотека классов iostreamS и итератор типа ostream_iterator как раз и позволяют понизить уровень сложности разработки таких программ. Использование манипулятора flush (в строке 33) гарантирует прохождение данных по каналу.

В программе 11.2.1 сыновний процесс сначала получает количество объектов, принимаемых от канала (в строке 36), а затем для считывания самих объектов использует объект IPipe класса istream.

// Программа 11.2.1

11 class multiplier{

12 float X;

13 public:

14 multiplier(float Value) { X = Value;}

15 float &operator()(float Y) { X = (X * Y);return(X);}

16 }; 17

18

19 int main(int argc,char *argv[])

20 {

21 char Value[50] ;

22 int Fd[2] ;

23 float Data;

24 vector<float> X;

25 int NumElements;

26 multiplier N(12.2);

27 strcpy(Value,getenv(«Fdin»));

28 Fd[0] = atoi(Value);

29 strcpy(Value,getenv(«Fdout»));

30 Fd[l] = atoi(Value);

31 ifstream IPipe;

32 ofstream OPipe;

33 IPipe.attach(Fd[0]) ;

34 OPipe.attach(Fd[l]) ;

35 ostream_iterator<float> OPtr(OPipe,"\n»);

36 IPipe » NumElements;

37 for(int N = 0;N < NumElements;N++)

38 {

39 IPipe » Data;

40 X.push_back(Data);

41 }

42 OPipe « X.size() « endl;

43 transform(X.begin(),X.end(),OPtr,N);

44 OPipe « flush;

45 return(0); 46

47 }

Сыновний процесс считывает элементы данных из канала, помещает их в вектор, азатем выполняет математические преобразования над каждым элементом вектора, после чего отправляет их назад родительскому процессу. Математические преобразования (строка43) выполняются с использованием стандартного С++-алгоритма transform и пользовательского класса multiplier. Алгоритм transform применяет к каждому элементу контейнера операцию, а затем результат этой операции помещает в контейнер-приемник. В данном случае контейнером-приемником служит объект Optr, который связан с объектом OPipe. Заголовки, которые необходимо включить в программу 11.2.1, приведены в разделе «Профиль программы 11.2.1».

Профиль программы 11.2.1

Имя программы program11-2b.cc

Описа н ие Программа представляет собой код сыновнего процесса, который запускается npoграммой 11.2. В этой программе для получения содержимого контейнера, отправленного из программы 11.2, используется объект класса ifstream. Для отправки через канал обработанной информации родительскому процессу в программе исполь-|зуется объект класса ostream_iterator и стандартный алгоритм transform.

Требуемые заголовки

<iostream>, algorithm>, <fstream>, <vector>, <iterator>, <stdlib.h>, |<string.h>, <unistd.h>.

Инструкции no компиляции и компоновке программ

с++ -o»programll-2b programll-2b.ee

Инструкции по выполнению [Эта программа запускается программой 11.2.

Несмотря на то что классы библиотеки iostream, итераторы типа istream_iterator и ostream_iterator упрощают программирование канала, они не изменяют его поведение. По-прежнему остаются в силе вопросы блокирования и проблемы, связанные с корректным порядком открытия и закрытия каналов, рассмотренные в главе 5. Но использование основных механизмов тех же методов объектно-ориентированного программирования все же позволяет понизить уровень сложности параллельного и распределенного программирования.

Методы, которые мы использовали для реализации объектно-ориентированных анонимных каналов, обладают двумя недостатками. Во-первых, любым процессам, которые взаимодействуют с другими процессами, нужен доступ к файловым дескрипторам, возвращаемым при вызове системной функции pipe (). Поэтому существует проблема получения этих файловых дескрипторов для всех процессов-участников. Эта проблема легко решается, если процессы связаны отношение м «родитель-потомок» (как в програ мм ах 11.1, 11.2 и 11.2.1), но в это м случае возникает другая проблема. Выходит, во-вторых, что процессы, которые используют неи м енованные каналы, должны быть связаны отношения м и. Это требование можно обойти с помощью схемы передачи дескриптора. Для решения этой проблемы используется структура FIFO (First In — First Out — первым прибыл, первым обслужен). Самое большое ее достоинство как раз и состоит в том, что к ней могут получить доступ процессы, не связанные никакими отношениями. Процессы должны выполняться на одном компьютере — это единственное, что должно их связывать. При этом процессы могут запускаться программами, реализованными на разных языках программирования и с использованием различных парадигм программирования (например, обобщенной или объектно-ориентированной). При групповых вычислениях и при использовании других конфигураций равноправных элементов можно воспользоваться преимуществами FIFO-очередей (иногда называе м ых именованными каналами), поскольку в UNIX- и Linux-среде FIFO-структура имеет имя (определяемое пользователем) и ее (в отличие от анонимных каналов) можно сравнить с «капитальным сооружением». FIFO — однонаправленная структура, а это значит, что пользователь именованного канала в среде UNIX должен открыть его либо для чтения, либо для записи, но не для того и другого одновременно. Именованные каналы, созданные в среде UNIX, остаются в файловой системе до тех пор, пока они не будут явно удалены с помощью вызова из программы функции unlink() или выполнения соответствующей команды из командной строки (например, команды rm). Именованным каналам при их создании присваивается эквивалент имени файла. Любой процесс, которому известно имя канала и который обладает необходимыми правами доступа, может открыть его, прочитать из него данные и записать их туда.

Чтобы связать анонимные каналы с объектами классов ifstream и ofstream, мы использовали нестандартное связывание с файловым дескриптором. Нестандартность ситуации вытекает из того, что «брак» между файловыми дескрипторами и iostreams-объектами пока не «освящен» стандартом ISO С++. Поэтому безопаснее использовать FIFO-структуры. К FIFO-файлу специального типа можно получить доступ с помощью имени в файловой системе, в которой «официально» поддерживается связывание с объектами С++-классов ifstream и ofstream. Поэтому точно так же, как мы упрощали межпроцессное взаимодействие (IPC) с помощью iostream-классов и анонимного канала, мы упрощаем доступ к FIFO-структуре. FIFO-структура, основные функции которой совпадают с функциями анонимного канала, позволяет распространить возможности взаимодействия на классы, не связанные никакими родственными отношениями. Однако каждая программа — участник взаимодействия должна при этом «знать» имена FIFO-структур. Это требование, казалось бы, напоминает ограничение, с котороым мы встречались при использовании файловых дескрипторов. Однако FIFO — это все же «шаг вперед». Во-первых, при открытии анонимного канала только система определяет, какие файловые дескрипторы доступны в данный момент. Это означает, что программист не в состоянии полностью контролировать ситуацию. Во-вторых, существует ограничение на количество файловых дескрипторов, котороми располагает система. В-третьих, поскольку FIFO-структурам имена присваиваются пользователем, то количество таких имен не ограничивается. Файловые дескрипторы должны принадлежать файлам, открытым ранее (и причем успешно), а FIFO-имена — это всего лишь имена. FIFO-имя определяется пользователем, а файловые дескрипторы— системой. Имена файлов связываются с объектами классов ifstream, fstream и ofstream с помощью либо конструктора класса либо метода open(). В программе 11.3.1 для связывания объектов классов ofstream и ifstream с FIFO-структурой используется конструктор.

// Программа 11.3.1

14 using namespace std;

15

16 const int FMode = S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH;

17

18 int main(int argc, char *argv[])

19 {

20

21 int Pid,Status,Size;

22 double Value;

25 mkfifo("/tmp/channel.l»,FMode) ;

26 mkfifo (" / tmp/channel. 2», FMode) ;

28 vector<double> X(100,13.0);

29 vector<double> Y;

30 ofstream OPipe("/tmp/channel.l»,ios::app);

31 ifstream IPipe("/tmp/channel.2»);

32 OPipe << X.size() « endl;

33 ostream_iterator<double> Optr(OPipe,"\n»);

34 copy(X.begin(),X.end(),Optr);

35 OPipe « flush;

36 IPipe » Size;

37 for (int N = 0;N < Size; N++)

38 {

39 IPipe » Value;

40 Y.push_back(Value);

41 }

42

43 IPipe.close();

44 OPipe.close();

45 unlink("/tmp/channel.1»);

46 unlink("/tmp/channel.2»);

47 cout « accumulate(Y.begin(),Y.end(),-13.0) « endl;

48

49 return(0);

50 }

В программе 11.3.1 используется две FIFO-структуры. Вспомните, что FIFO-структуры являются однонаправленными компонентами. Поэтому, если процессы должны обмениваться данными, то необходимо использовать по крайней мере две FIFO-структуры. В программе 11.3.1 они называются channel.1 и channel.2. Обратите внимание на установку флагов полномочий для FIFO-структур (строка 16). Эти полномочия означают, что владелец FIFO-структуры имеет право доступа для чтения и записи, а все остальные — право доступа только для чтения. При выполнении строки 30 FIFO-структура channel.1 будет открыта только для вывода данных. Тот же результат можно было бы получить следующим образом : OPipe. open ("/tmp/channel.1», ios::app);

Используемые здесь параметры алгоритма open () означают, что FIFO-структура будет открыта в режиме дозаписи. В программе 11.3.1 алгоритм copy () используется для вставки объектов в объект OPipe типа fstream и косвенно в FIFO-структуру. Мы могли бы также использовать здесь объект типа

fstream:fstreamOPipe("/tmp/channel.l», ios::out | ios::app);

В этом случае взаимодействие процессов было бы ограничено выводом данных только в режиме дозаписи. Если бы мы не использовали флаг ios: :app , попытка объекта типа ofstream создать FIFO-сгруктуру (см. строку 30) была бы неудачной.

К сожалению, такой вариант работать не будет. Создание FIFO-структур находится в компетенции функции mkfifo(). В строках 45 и 46 программы 11.3.1 FIFO-структуры удаляются из файловой систе м ы. С этого м о м ента любые процессы, в которых открыты FIFO-структуры, еще в состоянии получить к ним доступ. Однако их имен больше не существует. Поэтому такие процессы не смогут использовать алгоритм open() или создать новые объекты типа ofstream или ifstream на основе и м ени, которое было «отсоединено». В строках 32-34, объекты типа ostream_ iterator и ofstream используются для вставки эле м ентов в FIFO-структуру. Обратите вни м ание на то, что програ мм а 11.3.1 не образует никаких ветвлений и не создает сыновних процессов. Программа 11.3.1 зависит от другой програ мм ы, которая должна считывать инфор м ацию из FIFO-структуры channel . 1 или записывать инфор м ацию в FIFO-структуру channel . 2 . Если такая программа не будет работать одновременно с программой 11.3.1, последняя останется заблокированной. Детали реализации приведены в разделе «Профиль программы 11.3.1».

Профиль программы 11.3.1

Имя программы program11-3a.cc

Описание Для пересылки контейнерного объекта через FIFO-структуру используются объекты ТИпа ostream_iterator и ofstream. Для извлечения информации из FIFO-структуры применяется объект типа ifstream.

Требуемые заголовки

<unistd.h>, <iomanip>, <algorithm>, <fstream.h>,<vector>,<iterator> <strstream.h>, <stdlib.h>, <sys/wait.h>, <sys/types.h>, <sys/stat.h> <fcntl.h>, <numeric>.

Инструкции по компиляции и компоновке программ

с++ -о program11-3a program113a.сс

Среда для тестирования

SuSE Linux 7.1, gcc 2.95.2, Solaris 8, Sun Workshop 6.

Инструкции по выполнению

./program11-3a & program11-3b

Примечания

Сначала запускается программа 11.3.1. Программа11.3.2 содержит инструкцию sleep, которая восполняет собой отсутствие реальной синхронизации.

Программа 11.3.2 считывает данные из FIFO-структуры channel. 1 и записывает информацию в FIFO-структуру channel. 2.

// Программа 11.3.2. Считывание данных из FIFO-структуры

// channel.l и запись информации в

// FIFO-структурУ channel.2

10 using namespace std; 11

12 class multiplier{

13 double X,-

14 public:

15 multiplier(double Value) { X = Value;}

16 double &operator()(double Y) { X = (X * Y);return(X);}

17 }; 18

19

20 int main(int argc,char *argv[])

21 { 22

23 double Size;

24 double Data;

25 vector<double> X;

26 multiplier R(1.5);

27 sleep(15);

28 fstream IPipe("/tmp/channel.1»);

29 ofstream OPipe("/tmp/channel.2»,ios::app);

30 if(IPipe.is_open()){

31 IPipe » Size;

32 }

33 else{

34 exit(l);

35 }

36 cout « «Количество элементов " << Size << endl;

37 for(int N = 0;N < Size;N++)

38 {

39 IPipe » Data;

40 X.push_back(Data);

41 }

42 OPipe « X.size() « endl;

43 ostream_iterator<double> Optr(OPipe,"\n»);

44 transform(X.begin(),X.end(),Optr,R);

45 OPipe << flush;

46 OPipe.close();

47 IPipe.close();

48 return(0); 49

50 }

Обратите внимание на то, что в программе 11.3.1 FIFO-стуктура channel.l открывается для вывода данных, а в программе 11.3.2 та же FIFO-структура channel. 1 — для ввода данных. Слелует иметь в виду, что FIFO-структуры действуют как однонаправленные механизмы связи, поэтому не пытайтесь пересылать данные в обоих направлениях! Достоинство использования iostreams -классов в сочетании с FIFO-структурами состоит в том, что мы можем использовать iostreams -методы применительно к FIFO-структурам. Например, в строкеЗО мы используем метод is_open() класса basic_filebuf, который позволяет определить, открыта ли FIFO-структура. Если она не открыта, то программа 11.3.2 завершается. Детали реализации программы 11.3.2 приведены в разделе «Профиль программы 11.3.2».

Профиль программы 11.3.2

Имя программы

programll-3b.ee

Описание

Программа считывает объекты из FIFO-структуры с помощью объекта типа ifstream. Для пересылки данных через FIFO-структуру здесь используется итератор типа ostream_iterator и стандартный алгоритм transform.

Требуемые заголовки

><unistd.h>, <iomanip>, <algorithm>, <fstream.h>, <vector>, <iterator>, <strstream.h>, <stdlib.h>, <sys/wait.h>, <sys/types.h>, <sys/stat.h>, ^<fcntl .h>, <numeric>.

Инструкции по компиляции и компоновке программ

с++ -о programll-3b programll-3b.сс

; Среда для тестирования

SuSE Linux 7.1, GCC 2.95.2, Solaris 8, Sun Workshop 6.0.

Инструкции по выполнению

program11.3a & program11-3b

Примечания

Cначала запускается программа11.3.1. Программа11.3.2 содержит инструкцию Sleep, которая восполняет собой отсутствие реальной синхронизации.

Упростить межпроцессное взаимодействие (IPC) можно не только с помощью iostreams-классов или классов istream_iterator и ostream_iterator, но и посредством инкапсуляции FIFO-механизма в FIFO-классе (листинг 11.23).

// Листинг 11.23. Объявление FIFO-класса

class fifo{

mutex Mutex;

//.. .

protected:

string Name; public:

fifo &operator<<(fifo &In, int X);

fifo &operator<<(fifo &In, char X);

fifo &operator>>(fifo &Out, float X);

//.. .

};

В этом случае мы можем легко создавать объекты класса fifo с помощью конструктора, а также передавать их как параметры и принимать в качестве значений, возвращаемых функциями. Мы можем использовать их в сочетании с классами стандартных контейнеров. Применение такой конструкции значительно сокращает объем кода, необходимого для функционирования FIFO-механизма. Более того, «классовый» подход создает условия для обеспечения типовой безопасности и вообще позволяет программисту работать на более высоком уровне.

Под каркасным понимается класс (или целал коллекция классов), который имеет заранее определенную структуру и представляет обобщенную модель поведения. Точно так же, как программы обеспечивают общие решения для конкретных задач, каркасные классы предоставляют конкретные решения для классов задач. Другими словами, каркас приложений содержит общую направленность выполнения кода для целого диапазона программ, которые решают задачи подобным образом. Поскольку каркас приложений представляет одно решение для семейства задач, то их можно назвать обощенными автономными мини-приложениями. .Каркасный класс служит своего рода проектом для мини-приложения. Он предлагает фунда м ентальную структуру (скелет), которую должно иметь приложение, не навязывал никаких деталей. Каркасный класс определяет отношения, распределяет обязанности, намечает порядок действий и протоколы между частями ПО в объектно-ориентированной архитектуре. Например, мы можем спроектировать класс языкового процессора, который должен содержать общую схему работы для целого диапазона приложений. Эта схема должна определить действия, которые необходимо выполнить для преобразования некоторого входного языка в за д анный выходной формат. Такой каркас состоит из нескольких об щ их частей ПО:

• компоненты проверки достоверности;

• компоненты выделения лексем;

• компоненты грамматического разбора;

• компоненты синтаксического анализа;

• компоненты лексического анализа.

Эти части ПО можно объединить, чтобы сформировать уже знакомую нам программную конструкцию (листинг11.24).

// Листинг 11.24. Объявление класса language_processor

// и определение метода process_input

class language_processor {

//...

protected:

virtual bool getString(void) = 0;

virtual bool validateString(void) = 0;

virtual bool parseString(void) = 0;

//...

public:

bool process_input(void);

};

bool language_processor::process_input(void) {

getString();

validateString();

parseString();

//.. .

compareTokens();

//.. .

}

Во-первых, класс language_processor является абстрактным и базовым, поскольку он содержит чисто виртуальные функции:

virtual bool getString(void) = 0;

virtual bool validateString(void) = 0;

virtual bool parseString(void) = 0;

Это означает, что класс language_processor не предназначен для непосредственного использования. Он служит в качестве проекта для производных классов. Особенно стоит остановиться на методе process_input (). Этот метод представляет собой план работы, которую предстои т обобщит ь классу language_processor. Во многих отношениях именно это и отличает каркасные классы от классов других типов. Каркасный класс описывает не только обобщенную структуру и характер отношений между компонентами, но содержит и заранее определенные последовательности выполняемых действий. Однако в таком своеобразном описании поведения не указываются детали его реализации. В данном случае модель поведения задается набором чисто виртуальных функций. Каркасный класс не определяет, как именно эти действия должны быть выполнены, — важно то, что они должны быть выполнены, причем в определенном порядке. А производный класс должен обеспечить реализацию всех чисто виртуальных функций. При этом ответственность за корректность выполняемых действий целиком возлагается на производный класс. Каркасные классы по определению — договорные классы. Для достижения успешного результата требуется надлежащее выполнение обеих частей договора. Каркасный класс намечает четкий план, а производный реализует этот план в виде конкретного определения чисто виртуальных функций. Последовательность действий, «намеченная» методом process_input (), соблюдается в таких приложениях.

• Компиляторы

• Интерпретаторы ко м анд

• Обработчики естественных языков

• Програ мм ы шифрования-дешифрирования

• Упаковка-распаковка

• Протоколы пересылки файлов

• Графические интерфейсы пользователей

• Контроллеры устройств

Корректная разработка каркасного класса language_processsor (при надлежащем его тестировании и отладке) позволяет ускорить разработку широкого диапазона приложений.

Понятие каркасного класса также полезно использовать при разработке приложений, к которым предъявляются требования параллелизма. Так, использование агент-ных каркасов и каркасов «классной доски» фиксирует базовую структуру параллелизма и схемы работы в этих структурах. Майкл Вулдридж в своей книге [51] предлагает следующий обобщенный цикл управления агентами.

Алгоритм: цикл управления агентами

В = ВО

while true do

get next percept p

В = brf(B,p)

I = deliberate(B)

П= plan(B,I)

execute(П)

end while_

Эта модель поведения реализуется широким диапазоном рациональных агентов. Если вы разрабатываете программу, в которой используются рациональные агенты, то скорее всего эта последовательность действий будет реализована в вашей программе. На фиксации последовательностей действий такого типа и «специализируются» каркасные классы. Для цикла управления агентами функции brf (), deliberate () и plan () должны быть объявлены чисто виртуальными функциями. Цикл управления агентами определяет, в каком порядке и как должны вызываться эти функции, а также сам факт того, что они должны быть вызваны. Однако конкретное содержание функции определит производный класс. При надлежащем определении цикла управления агентами будет решен целый класс проблем. Ведь системы, состоящие из множества параллельно выполняющихся агентов, постепенно становятся стандартом для реализации приложений параллельного программирования. Такие системы часто называют мультиагептпыми системами. Агентно-ориентированные системы мы рассмотрим в главе 12, а пока отметим, что агентные каркасные классы позволяют понизить уровень сложности разработки мультиагентных систем, что очень ценно в свете того, что мультиагентные системы становятся предпочтительным вариантом архитектуры для реализации средне- и крупномасштабных приложений, которые требуют реализации параллелизма или массового параллелизма.

Каркасные классы обеспечивают своих потомков не только планом действий (что весьма полезно для параллельных или распределенных систем), но и такими компонентами синхронизации, как объектно-ориентированные мьютексы, семафоры и потоки сообщений. Структура «классной доски» — полезное средство для взаимодействия множества агентов— представляет собой критический раздел, поскольку сразу несколько агентов должны иметь возможность одновременно считывать из нее информацию и записывать ее туда. Следовательно, каркасный класс должен обеспечить базовую структуру для отношений между агентами, компонентами синхронизации и»классной доской». Например, листинг 11.25 содержит два метода, которые каркасный класс мог бы использовать для доступа к «классной доске».

// Листинг 11.25. Определение методов recordMessge() и

// getMessage() для класса agent_framework

int agent_framework::recordMessage(void) {

Mutex.lock();

BlackBoardStream << Agent[N].message(); Mutex.unlock();

}

int agent_framework::getMessage(void) {

}

Mutex.lock();

BlackBoardStream » Values; Agent[N].perceive(Values); Mutex.unlock();

Здесь каркасный класс должен защищать доступ к «классной доске» с помощью объектов синхронизации. Поэтому, когда агенты считывают сообщения с «классной доски» или записывают их туда, синхронизация уже будет обеспечена каркасным классом. Программисту не нужно беспокоиться о синхронизации доступа к «классной доске». Базовая структура агентно-ориентированного каркасного класса agent_framework показана на рис. 11.11.

Рис. 11.11. Базовая структура каркасного класса agent_framework

Обратите внимание на то, что каркасный класс инкапсулирует объектно-ориентированные мьютексы и переменные условий. Агентно-ориентированный каркасный класс (см. рис. 11.11) для организации взаимодействия процессов в MPI- либо PVM-ориентированной системе должен использовать MPI- либо PVM-потоки сообщений. Вспомните, что эти потоки сообщений были разработаны как интерфейсные классы, что позволяет программисту для доступа к PVM- или MPI-классу использовать iostreams-представление. Если MPI- или PVM-классы не используются, агенты могут взаимодействовать через сокеты, каналы или даже общую память. В любом случае мы рекомендуем реализовать примитивы синхронизации с помощью интерфейсных классов, которые упрощают их использование. Структура «классной доски», показанная на рис. 11.11, является объектно-ориентированной и использует преимущества универсальности, обеспечиваемой шаблонными классами, что также упрощает реализацию параллелизма. Агенты, выполняемые параллельно, представляют эффектив-кую модель параллельного и распределенного программирования.

Проблемы параллельного программирования, представленные в главе 2, можно эффективно решить, используя «строительные блоки», рассмотренные в этой главе. Роль интерфейсного класса в упрощении использования библиотек функций трудно преувеличить. Интерфейсный класс вносит логичность API-интерфейса путем заключения в оболочку вызовов функций из таких библиотек, как MPI или PVM. Интерфейсные классы обеспечивают типовую безопасность и возможность многократного использования кода, а также позволяют программисту работать в привычной «системе координат», как с PVM- или MPI-потоками данных. Межпроцессное взаимодействие (IPC) упрощается путем связывания канала или потоков сообщений сюБЧгеатБобъектами и перегрузки операторов вставки («) и извлечения (») для пользовательских классов. Класс ostream_iterator доказывает свою полезность в «оптовой» пересылке контейнерных объектов и их содержимого между процессами. Итераторы типа ostream_iterator и istream_iterator также обеспечивают свя-зующее звено между стандартными алгоритмами и IPC-компонентами и методами. Поскольку модель передачи сообщений используется во многих параллельных и распределенных приложениях, то любой метод, который упрощает передачу различных типов данных между процессами, упрощает программирование приложения в целом. К таким способам упрощения относится использование iostreams-классов и итераторов типа ostream_iterator и istream_iterator. Каркасный класс представлен здесь как базовый строительный блок параллельных приложений. Мы рассматриваем классы, подобные классам мьютексов, переменных условий и потоков, как компоненты низкого уровня, которые должны быть скрыты от программиста в каркасном классе (где это возможно!). При создании средне- и крупномасштабных приложений, которые тре-буют реализации параллелизма, программист не должен «застревать» на этих низкоуровневых компонентах. В идеале для удовлетворения требований параллельной обработки каркасный класс должен быть строительным блоком базового уровня и обеспечивать нас «готовыми» схемами равноправных элементов и взаимодействия типа «клиент-сервер». Мы можем использовать различные типы каркасных классов: для обработки чисел, баз данных или применения агентов, технологии «классной доски», GUI и т.д.

Метод, который мы предлагаем для реализации параллелизма, состоит в построении приложений на базе коллекции каркасных классов, которые уже оснащены надлежащими компонентами синхронизации, связанными соответствующими отношениями. В главах 12 и 13 мы подробнее остановимся на каркасных классах, которые поддерживают параллелизм. Мы также рассмотрим использование стандартных С++-алгоритмов, контейнеров и объектов функций для управления процессом создания множества задач или потоков в приложениях, требующих параллелизма.

Примечания:

1

POSIX— Portable Operating System Interface for computer environments— интерфейс переносимой операционной системы (набор стандартов IEEE, описывающих интерфейсы ОС для UNIX).

18

Вообще-то «API-интерфейс» - это «масло масляное»