
- •Введение
- •Этапы большого пути
- •Библиотеки для параллельного и распределенного программирования
- •Новый единый стандарт спецификаций unix
- •Для кого написана эта книга
- •Среды разработки
- •Дополнительный материал Диаграммы uml
- •Профили программы
- •Параграфы
- •Тестирование кода и его надежность
- •Ждем ваших отзывов!
- •Благодарности
- •Преимущества параллельного программирования
- •Что такое параллелизм
- •Два основных подхода к достижению параллельности
- •Преимущества параллельного программирования
- •Простейшая модель параллельного программирования (pram)
- •Простейшая классификация схем параллелизма
- •Преимущества распределенного программирования
- •Простейшие модели распределенного программирования
- •Мультиагентные распределенные системы
- •Минимальные требования
- •Декомпозиция
- •Синхронизация
- •Базовые уровни программного параллелизма
- •Параллелизм на уровне инструкций
- •Параллелизм на уровне подпрограмм
- •Параллелизм на уровне объектов
- •Параллелизм на уровне приложений
- •Стандарт mpi
- •Pvm: стандарт для кластерного программирования
- •Стандарт corba
- •Реализации библиотек на основе стандартов
- •Среды для параллельного и распределенного программирования
- •Проблемы параллельного и распределенного программирования
- •Кардинальное изменение парадигмы
- •Проблемы координации
- •Проблема №3: взаимоблокировка
- •Проблема №4: трудности организации связи
- •Отказы оборудования и поведение по
- •Негативные последствия излишнего параллелизма и распределения
- •Выбор архитектуры
- •Различные методы тестирования и отладки
- •Связь между параллельным и распределенным проектами
- •Определение процесса
- •Два вида процессов
- •Блок управления процессами
- •Анатомия процесса
- •Состояния процессов
- •Планирование процессов
- •Стратегия планирования
- •Использование утилиты ps
- •Установка и получение приоритета процесса
- •Переключение контекста
- •Создание процесса
- •Отношения между родительскими и сыновними процессами
- •Утилита pstree
- •Использование системной функции fork()
- •Использование семейства системных функций exec
- •Функции execl ()
- •Функции execv ()
- •Определение ограничений для функций exec ()
- •Чтение и установка переменных среды
- •Использование posix-функций для порождения процессов
- •Идентификация родительских и сыновних процессов с помощью функций управления процессами
- •Завершение процесса
- •Ресурсы процессов
- •§ 3.1 • Граф распределения ресурсов ,
- •Типы ресурсов
- •Posix-функции для установки ограничений доступа к ресурсам
- •Асинхронные и синхронные процессы
- •Функция wait ()
- •Разбиение программы на задачи
- •Линии видимого контура
- •Определение потока
- •Контекстные требования потока
- •Сравнение потоков и процессов
- •Различия между потоками и процессами
- •Потоки, управляющие другими потоками
- •Преимущества использования потоков
- •Переключение контекста при низкой (ограниченной) доступности процессора
- •Возможности повышения производительности приложения
- •Простая схема взаимодействия между параллельно выполняющимися потоками
- •Упрощение структуры программы
- •Недостатки использования потоков
- •Потоки могут легко разрушить адресное пространство процесса
- •Один поток может ликвидировать целую программу
- •Потоки не могут многократно использоваться другими программами
- •Анатомия потока
- •Атрибуты потока
- •Планирование потоков
- •Состояния потоков
- •Планирование потоков и область конкуренции
- •Стратегия планирования и приоритет
- •Изменение приоритета потоков
- •Ресурсы потоков
- •Модели создания и функционирования потоков
- •Модель делегирования
- •Модель с равноправными узлами
- •Модель конвейера
- •Модель «изготовитель-потребитель»
- •Модели spmd и мрмd для потоков
- •Введение в библиотеку Pthread
- •Анатомия простой многопоточной программы
- •Компиляция и компоновка многопоточных программ
- •Создание потоков
- •Получение идентификатора потока
- •Присоединение потоков
- •Создание открепленных потоков
- •Использование объекта атрибутов
- •Создание открепленных потоков с помощью объекта атрибутов
- •Управление потоками
- •Завершение потоков
- •Точки аннулирования потоков
- •Очистка перед завершением
- •Управление стеком потока
- •Установка атрибутов планирования и свойств потоков
- •Установка области конкуренции потока
- •Использование функции sysconf ()
- •Управление критическими разделами
- •Безопасность использования потоков и библиотек
- •Разбиение программы на несколько потоков
- •Использование модели делегирования
- •Использование модели сети с равноправными узлами
- •Использование модели конвейера
- •Использование модели «изготовитель-потребитель»
- •Создание многопоточных объектов
- •Синхронизация параллельно выполняемых задач
- •Координация порядка выполнения потоков
- •Взаимоотношения между синхронизируемыми задачами
- •Отношения типа старт-старт (cc)
- •Отношения типа финиш-старт (фс)
- •Отношения типа старт-финиш (сф)
- •Отношения типа финиш-финиш (фф)
- •Синхронизация доступа к данным
- •Модель ррам
- •Параллельный и исключающий доступ к памяти
- •Что такое семафоры
- •Операции по управлению семафором
- •Мьютексные семафоры
- •Использование мьютексного атрибутного объекта
- •Использование мьютексных семафоров для управления критическими разделами
- •Блокировки для чтения и записи
- •Использование блокировок чтения-записи для реализации стратегии доступа
- •Условные переменные
- •Использование условных переменных для управления отношениями синхронизации
- •Объектно-ориентированный подход к синхронизации
- •Классические модели параллелизма, поддерживаемые системой pvm
- •Выполнение pvm-программы в виде двоичного файла
- •Запуск pvm-программ c помощью pvm-консоли
- •Запуск pvm-программ c помощью xpvm
- •Требования к pvm-программам
- •Методы использования pvm-задач
- •§ 6.1. Обозначение сочетаний
- •6.3. Базовые меха н измы pvm 233
- •Базовые механизмы pvm
- •Функции управления процессами
- •6.3. Базовые меха н измы pvm 235
- •Упаковка и отправка сообщений
- •6.3. Базовые механизмы pvm 237
- •Доступ к стандартному входному потоку (stdin) и стандартному выходному потоку (stdout) со стороны pvm-задач
- •Получение доступа к стандартному выходному потоку (cout) из сыновней задачи
- •Обработка ошибок, исключительных ситуаций и надежность программного обеспечения
- •Надежность программного обеспечения
- •Отказы в программных и аппаратных компонентах
- •Определение дефектов в зависимости от спецификаций по
- •Обработка ошибок или обработка исключительных ситуаций?
- •Надежность по: простой план
- •План а: модель возобновления, план б: модель завершения
- •Использование объектов отображения для обработки ошибок
- •Классы исключений
- •Классы runtime__error
- •Классы logic_error
- •Выведение новых классов исключений
- •Защита классов исключений от исключительныхситуаций
- •Диаграммы событий, логические выражения и логические схемы
- •Распределенное объектно-ориентированное программирование
- •Декомпозиция задачи и инкапсуляция ее решения
- •Взаимодействие между распределенными объектами
- •Синхронизация взаимодействия локальных и удаленных объектов
- •Обработка ошибок и исключений в распределенной среде
- •Доступ к объектам из других адресных пространств
- •Брокеры объектных запросов (orb)
- •Язык описания интерфейсов (idl):более «пристальный» взгляд на corba-объекты
- •Анатомия базовой corba-программы потребителя
- •Анатомия базовой corba-программы изготовителя
- •Базовый npoeкт corba-приложения
- •Получение ior-ссылки для удаленных объектов
- •Служба имен
- •§ 8.1. Семантические сети
- •Использование службы имен и создание именных контекстов
- •Служба имен «потребитель-клиент»
- •Подробнее об объектных адаптерах
- •Хранилища реализаций и интерфейсов
- •Простые pacnpeделенные Web-службы, использующие corba-спецификацию
- •Маклерская служба
- •Парадигма «клиент-сервер»
- •Реализация моделей spmd и mpmd с помощью шаблонов и mpi-программирования
- •Декомпозиция работ для mpi-интерфейса
- •Дифференциация задач по рангу
- •Группирование задач по коммуникаторам
- •Анатомия mpi-задачи
- •Использование шаблонных функций для представления mpi-задач
- •Реализация шаблонов и модельБрмо (типы данных)
- •Использование полиморфизмадля реализации mpmd-модели
- •Введение mpmd-модели c помощью функций -объектов
- •Как упростить взаимодействие между mpi-задачами
- •Визуализация проектов параллельных и распределенных систем
- •Визуализация структур
- •Классы и объекты
- •Отображение информации об атрибутах и операциях класса
- •Организация атрибутов и операций
- •Шаблонные классы
- •Отношения между классами и объектами
- •Интерфейсные классы
- •Организация интерактивных объектов
- •Отображение параллельного поведения
- •Сотрудничество объектов
- •Процессы и потоки
- •Отображение нескольких потоков выполнения и взаимодействия между ними
- •Последовательность передачи сообщений между объектами
- •Деятельность объектов
- •Конечные автоматы
- •Параллельные подсостояния
- •Распределенные объекты
- •Визуализация всей системы
- •Визуализация развертывания систем
- •Архитектура системы
- •Проектирование компонентов для поддержки параллелизма
- •Как воспользоваться преимуществами интерфейсных классов
- •Подробнее об объектно-ориентированном взаимном исключении и интерфейсных классах
- •«Полуширокие» интерфейсы
- •Поддержка потокового представления
- •Перегрузка операторов "«" и "»" для pvm-потоков данных
- •Пользовательские классы, создаваемые для обработки pvm-потоков данных
- •Объектно-ориентированные каналы и fifo-очереди как базовые элементы низкого уровня
- •Связь каналов c iostream-объектами с помощью дескрипторов файлов
- •18 Cerr « «Ошибка при создании канала " « endl;
- •Доступ к анонимным каналам c использованием итератора ostream_iterator
- •Fifo-очереди (именованные каналы),
- •Интерфейсные fifo-классы
- •Каркасные классы
- •Реализация агентно-ориентированных архитектур
- •Что такое агенты
- •Агенты: исходное определение
- •Типы агентов
- •В чем состоит разница между объектами и агентами
- •Понятие об агентно-ориентированном программировании
- •§ 12:1 Дедукция, индукция и абдукция
- •Роль агентов в распределенном программировании
- •Агенты и параллельное программирование
- •Базовые компоненты агентов
- •Когнитивные структуры данных
- •Методы рассуждений
- •Типы данных предположений и структуры убеждений
- •Класс агента
- •Цикл активизации агента
- •Простая автономность
- •12.6. Резюме
- •Реализация технологии «классной доски» с использованием pvm-средств, потоков и компонентов
- •Модель «классной доски»
- •Методы структурирования «классной доски»
- •Анатомия источника знаний
- •Стратегии управления для «классной доски»
- •Реализация модели «классной доски» с помощью corba-объектов
- •Пример использования corba-объекта «классной доски»
- •Реализация интерфейсного класса black_board
- •Порождение источников знаний в конструкторе «классной доски»
- •Порождение источников знаний с помощью pvm-задач
- •Связь «классной доски» и источников знаний
- •Активизация источников знаний с помощью posix-функции spawn()
- •Реализация модели «классной доски» с помощью глобальных объектов
- •Активизация источников знаний с помощью потоков
- •Приложение a
- •Диаграммы классов и объектов
- •Диаграммы сотрудничества
- •Диаграммы последовательностей
- •A.2.3. Диаграммы видов деятельности
- •A.3. Диаграммы состояний
- •A.4. Диаграммы пакетов
- •Приложение б 26
Использование объектов отображения для обработки ошибок
Компонент отображения (map) можно использовать как составную часть стратегии обработки ошибок или обработки исключений. Назначение отображения — связать один элемент с другим. Например, отображение можно использовать для связи номеров ошибок с их описаниями:
//.. .
map<int,string> ErrorTable;
ErrorTable[123] = «Деление на нуль»;
ErrorTable[4556] = «Отсутствие тонального вызова»;
//. . .
Здесь число 123 связано с описанием «Деление на нуль». Тогда при выполнении инструкции
cout « ErrorTable[123] « endl;
в объект выходного потока cout будет записана строка «Деление на нуль».
Помимо отображения встроенных типов данных, можно также отображать (т.е. находить соответствие) определенные пользователем объекты, содержащие данные встроенных типов. Вместо того, чтобы некоторое отображение просто возвращало описательное сообщение для каждого номера ошибки, можно позаботиться о том, чтобы оно возвращало объект с соответствующим номером ошибки. Этот объект может иметь методы, предназначенные для коррекции ошибок, составления отчетов об ошибках и их регистрации (записи ошибок в системный журнал). Например, предположим, что у нас есть следующий определенный пользователем объект:
defect_response:
class defect_response{
protected: //. . .
int DefectNo;
string Explanation;
public:
bool operator<(defect_response &X);
virtual int doSomething(void); string explanation(void);
//...
};
Теперь мы можем внести в отображение объекты типа defect_response:
//...
map<int,defect_reponse *> ErrorTable;
defect_response * Response;
Response = new defect_response;
ErrorTable[123] = Response;
//...
Этот код связывает объект отклика (на ошибку) с номером ошибки 123. Благодаря полиморфизму объект отображения может содержать указатели на любой объект типа defect_response или любой объект, который выведен из него. Предположим, что у нас есть следующий класс:
class exception_response : public defect_response{
//.. . public:
int doSomething(void)
//...
};
Этот класс exception_response является потомко м класса defect_response, поэтому мы можем внести в объект ErrorTable указатели на тип exception_re sponse.
//...
map<int,defect_reponse *> ErrorTable;
defect_response * Response;
exception_response *Response2;
Response = new defect_response;
Respone2 = new exception_response;
ErrorTable[123] = Response; // Хранит объект типа
// defect_response.
ErrorTable[456] = Response2; // Хранит объект типа
// exception_response.
//...
Это определение означает, что объект типа ErrorTable может связывать с соответствующим но м ером ошибки различные объекты (с различными описаниями и характеристиками). Следовательно, при вызове метода doSomething() объект ProblemSolver будет выполнять различные наборы инструкций:
//...
defect_response *ProblemSolver;
ProblemSovler = ErrorTable[123];
ProblemSolver->doSomething();
ProblemSovler = ErrorTable[456];
ProblemSovler->doSomething();
//...
Несмотря на то что Переменная ProblemSolver представляет собой указатель на объект defect_response, полиморфизм позволяет этой переменной указывать на объект типа exception_response или любой другой объект, выведенный из класса defect_response. Поскольку метод doSomething () объявлен виртуальным в классе defect_response, компилятор может выполнить динамическое связывание. Это дает гарантию корректного вызова метода doSomething() при выполнении приложения. Именно динамическое связывание позволяет каждому потомку класса defect_response определить собственный метод doSomething (). Нам нужно, чтобы вызов метода doSomething() зависел от того, ссылка на какой именно потомок класса defect_response используется при этом. Рассматриваемый метод позволяет связывать номера ошибок с объектами, имеющими отношение к обработке определенных сбойных ситуаций. С помощью этого метода можно значительно упростить код обработки ошибок. В листинге 7.1, например, показано, как значение, возвращаемое некоторой функцией, можно использовать для выбора соответствующего объекта обработки ошибок.
// Листинг 7.1. Использование значений, возвращаемых
// функцией, для определения корректного
// объекта типа ErrorHandler
void importantOperation(void) {
//. . .
Result = reliableOperation(); if(Result != Success){
defect_response *Solver;
Solver = ErrorTable[Result];
Solver->doSomething();
}
else{
// Продолжение обработки.
}
// . . .
}
В листинге 7.1 обратите внимание на то, что мы не используем последовательность if- или case-инструкций. Объект отображения позволяет получить непосредственный доступ к желаемому объекту обработки ошибок по индексу. Конкретный метод doSomething(), вызываемый в листинге 7.1, зависит от значения переменной Result. Безусловно, данный пример демонстрирует упрощенную схему обработки ошибочных ситуаций. Так, например, в листинге 7.1 не показано, кто (или что) отвечает за управление динамически выделяемой памятью для объектов, хранимых в отображении ErrorTable. Кроме того, здесь не учтено, что функции reliableOperation() и doSomething() могут выполниться неудачно. Поэтому реальный код будет, конечно же, несколько сложнее, чем тот, что приведен в листингe 7.1. Но все же этот пример ясно показывает, как одним «ударом» обработать множество ситуаций сбоя. Мы можем пойти еще дальше. В листинге 7.1 предполагается, что все возможные ошибки будут охвачены объектами типа ErrorTable. Все ErrorTable-объекты представляют собой либо объекты типа defect_response, либо объекты, выведенные из класса defect_response. А что, если у нас будет несколько семейств классов обработки ошибок? В листинге 7.2 показано, как с помощью шаблонов сделать функцию importantOperation () более общей.
// Листинг 7.2. Использование шаблона в функции // importantOperation()
template<class T,class U> int importantOperation(void) {
T ErrorTable; //.. .
U *Solver; //...
Solver = ErrorTable[Result]; Solver->doSomething () ; //...
};
В листинге 7.2 тип ErrorTable не ограничен объекта м и класса defect_response. Этот метод позволяет упростить код обработки ошибок и повысить его гибкость. Здесь демонстрируется использование полиморфизма как по вертикали, так и по горизонтали, что чрезвычайно важно для SPMD- и MPMD-программ. Как упростить программы, реализующие параллелизм с помощью шаблонов и полиморфизма, описано в главе 9. Использование объектов отображения и объектов обработки ошибок — это важнал составляющал повышения надежности ПО. Помимо методов обработки ошибок, мы можем также воспользоваться преимуществами механизма обработки исключительных ситуаций и классов исключений, прелусмотренных в С++ (этому посвящен следующий раздел).
Механизмы обработки исключительных ситуаций в С++
В идеале во время тестирования и отладки должны быть ликвидированы все дефекты протраммы или по крайней мере максимально возможное их количество. Кроме того, следует обработать нежелательные и неудобные условия с использованием обычной программной логики. После устранения всех (или почти всех) дефектов и обработки нежелательных и неудобных условий все остальные «неприятности» попадают в разряд исключительных ситуаций. Обработка исключительных ситуаций в С++ по д держивается с помощью трех ключевых слов: try, throw и catch. Любой код, сталкивающийся сисключительной ситуацией, с которой он не в силах справиться самостоятельно, генерирует исключение «в надежде» на то, что с ней совладает некоторый другой обработчик (расположенный где-то в другом месте программы) (Б. Страуструп, Язык программирования С++ , 1997). Для генерирования объекта некоторого специального типа (типа исключения) используется ключевое слово throw. При этом происходит передача управления обработчику исключения, который предназначен д л я обработки объектов данного типа. Д л я идентификации обработчиков, предназначенных д л я перехвата объектов исключений, используется ключевое слово catch. Рассмотрим пример.
void importantOperation {
/ / executeImportCode ()
// Возникает исключительная ситуация.
impossible_condition ImpossibleCondition;
throw ImpossibleCondition;
//...
}
catch (impossible_condition &E) {
// Выполнение действий, связанный с объектом E.
//...
}
Функция importantOperation( ) пытается выполнить свою работу и сталкивается с необычными условиями, с которыми она не в состоянии справиться. В нашем примере она создает объект типа impossible_condition и использует ключевое слово throw для генерирования этого объекта. Блок кода, в котором используется ключевое слово catch, предназначен для перехвата объектов типа impossible_condition. Этот блок кода называется обработчиком исключений. Обработчики исключений связаны с блоками кода, поме щ енными в try -выражения. Назначение try -блоков — обозначить область, в которой возможно возникновение исключительной ситуации. Блок catch должен сразу же следовать за соответствующим try -блоком или другим catch -блоком. Вот пример:
try{
//...
importantOperation();
//. . .
}
catch(impossible_condition &E) {
// Выполнение действий, связанных с объектом E.
// - . .
Здесь при выполнении функции importantOperation() возможно возникновение условий, с которыми она не в состоянии справиться. В этом случае функция сгенерирует исключение, в результате чего управление будет передано первому обработчику, который принимает объект исключений типа impossible_condition. Этот обработчик либо сам справится с этой исключительной ситуацией, либо сгенерирует исключение, с которым придется иметь дело другому обработчику исключений. Объекты, генерируемые при исключительных ситуациях, могут быть определены пользователем, причем они могут просто содержать коды ошибок или сообщения об ошибках, которые способны помочь обработчику исключений выполнить его работу. Если бы мы использовали объекты, подобные объектам типа exception_response из листингов 7.1 и 7.2, то обработчик исключений мог бы применить их для решения проблемы либо для восстановления работоспособного состояния программы. Для создания объектов исключений можно также использовать встроенные С++-классы исключений.