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

Эта книга посвящена всем программистам, и « безвредным» хакерам, инженерам-полуночникам и бесчисленным добровольцам, которые без устали и сожаления отдают свой талант, мастерство, опыт и время, чтобы сделать открытые программные продукты реальностью и совершить революцию в Linux. Без их вклада кластерное, MPP-, SMP-и распределенное программирование не было бы столь доступным для всех желающих, каким оно стало в настоящее время.

Введение

В этой книге представлен архитектурный подход к распределенному и параллельному программированию с использованием языка С++. Особое внимание уделяется применению стандартной С++-библиотеки, алгоритмов и контейнерных классов в распределенных и параллельных средах. Кроме того, мы подробно разъясняем методы расширения возможностей языка С++, направленные на решение задач программирования этой категории, с помощью библиотек классов и функций. При этом нас больше всего интересует характер взаимодействия средств С++ с новыми стандартами POSIX и Single UNIX применительно к организации многопоточной обработки. Здесь рассматриваются вопросы объединения С++-программ с программами, написанными на других языках программирования, для поиска «многоязычных» решений проблем распределенного и параллельного программирования, а также некоторые методы организации программного обеспечения, предназначенные для поддержки этого вида программирования.

В книге показано, как преодолеть основные трудности параллелизма, и описано, что понимается под производным распараллеливанием. Мы сознательно уделяем внимание не методам оптимизации, аппаратным характеристикам или производительности, а способам структуризации компьютерных программ и программных систем ради получения преимуществ от параллелизма. Более того, мы не пытаемся применить методы параллельного программирования к сложным научным и математическим алгоритмам, а хотим познакомить читателя с мультипарадигматическим подходом к решению некоторых проблем, которые присущи распределенному и параллельному программированию. Чтобы эффективно решать эти задачи, необходимо сочетать различные программные и инженерные подходы. Например, методы объектно-ориентированного программирования используются для решения проблем «гонки» данных и синхронизации их обработки. При многозадачном и многопоточном управлении мы считаем наиболее перспективной агентно-ориентированную архитектуру. А для минимизации затрат на обеспечение связей между объектами мы привлекаем методологию «классной доски» (стратегия решения сложных системных задач с использованием разнородных источников знаний, взаимодействующих через общее информационное поле). Помимо объектно-ориентированного, агентно-ориентированного и AI-ориентированного (AI — сокр. от artificial intelligence — искусственный интеллект) программирования, мы используем параметризованное (настраиваемое) программирование для реализации обобщенных алгоритмов, которые применяются именно там, где нужен параллелизм. Опыт разработки программного обеспечения всевозможных форм и объемов позволил нам убедиться в том, что для успешного проектирования программных средств и эффективной их реализации без разносторонности (универсальности) применяемых средств уже не обойтись. Предложения, идеи и решения, представленные в этой книге, отражают практические результаты нашей работы.

Этапы большого пути

При написании параллельных или распределенных программ, как правило, необходимо «пройти» следующие три основных этапа.

1. Идентификация естественного параллелизма, который существует в контексте предметной области.

2. Разбиение задачи, стоящей перед программным обеспечением, на несколько подзадач, которые можно выполнять одновременно, чтобы достичь требуемого уровня параллелизма.

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

Эти три этапа достигаются при условии параллельного решения следующих проблем:

• «гонка» данных

• обнаружение взаимоблокировки

• частичный отказ

• бесконечное ожидание

• взаимоблокировка

• отказ средств коммуникации

• регистрация завершения работы

• отсутствие глобального состояния

• проблема многофазной синхронизации

•  несоответствие протоколов

• локализация ошибок

• отсутствие средств централизованного

• распределения ресурсов

В этой книге разъясняются все названные проблемы, причины их возникновения и возможные пути решения.

Наконец, в некоторых механизмах, выбранных нами для обеспечения параллелизма, в качестве протокола используется TCP/IP (Transmission Control Protocol/Internet Protocol— протокол управления передачей/протокол Internet). В частности, имеются в виду следующие механизмы: библиотека MPI (Message Passing Interface — интерфейс для передачи сообщений), библиотека PVM (Parallel Virtual Machine — параллельная виртуальная машина) и библиотека MICO (или CORBA — Common Object Request Broker Architecture — технология построения распределенных объектных приложений). Эти механизмы позволяют использовать наши подходы в среде Internet/Intranet, а это значит, что программы, работающие параллельно, могут выполняться на различных сайтах Internet (или корпоративной сети intranet) и общаться между собой посредством передачи сообщений. Многие эти идеи служат в качестве основы для построения инфраструктуры Web-служб. В дополнение к MPI- и PVM-процедурам, используемые нами CORBA-объекты, размещенные на различных серверах, могут взаимодействовать друг с другом через Internet. Эти компоненты можно использовать для обеспечения различных Internet/Intranet-служб.

Подход

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

Почему именно С++

Существуют С++-компиляторы, которые работают практически на всех известных платформах и в операционных средах. Национальный Институт Стандартизации США (American National Standards Institute — ANSI) и Международная организация по стандартизации (International Organization for Standardization — ISO) определили стандарты для языка С++ и его библиотеки. Существуют устойчиво работающие, так называемые открытые (open source) (т.е. лицензионные программы вместе с их исходными текстами, не связанные ограничениями на дальнейшую модификацию и распространение с сохранением информации о первичном авторстве и внесенных изменениях), а также коммерческие реализации этого языка. Язык С++ был быстро освоен научными работниками, проектировщиками и профессиональными разработчиками всего мира. Его использовали для решения самых разных (по объему и форме) проблем: для написания как отдельных драйверов устройств, так и крупномасштабных промышленных приложений. Язык С++ поддерживает мультипарадигматический подход к разработке программных продуктов и библиотек, которые делают средства параллельного и распределенного программирования легко доступными.

Библиотеки для параллельного и распределенного программирования

Для параллельного программирования на основе С++ используются такие библиотеки, как MPICH (реализация библиотеки MPI), PVM и Pthreads (POSIX [1] Threads). Для распределенного программирования применяется библиотека MICO (С++-реализация стандарта CORBA). Стандартная библиотека С++ (С++ Standard Library) в сочетании с CORBA и библиотекой Pthreads обеспечивает поддержку концепций агентно-ориентированного программирования и программирования на основе методологии «классной доски», которые рассматриваются в этой книге.

Новый единый стандарт спецификаций UNIX

Новый единый стандарт спецификаций UNIX (Single UNIX Specifications Standard) версии 3 — совместный труд Института инженеров по электротехнике и электронике (Institute of Electrical and Electronics Engineers — IEEE [2]) и организации Open Group — был выпущен в декабре 2001 года. Новый единый стандарт спецификаций UNIX реализует стандарты POSIX и способствует повышению уровня переносимости программных продуктов. Его основное назначение — дать разработчикам программного обеспечения единый набор API-функций (Application Programming Interface — интерфейс прикладного программирования, т.е. набор функций, предоставляемый для использования в прикладных программах), поддерживаемых каждой UNIX-системой. Этот документ обеспечивает надежный «путеводитель» по стандартам для программистов, которые занимаются многозадачными и многопоточными приложениями. В этой книге, рассматривая темы создания процессов, управления процессами, использования библиотеки Pthreads, новых процедур posix_spawn(), POSIX-семафоров и FIFO-очередей f irst- i n, f irst- o ut— «первым поступил, первым обслужен»), мы опираемся исключительно на новый единый стандарт спецификаций UNIX. В приложении Б представлены выдержки из этого стандарта, которые могут быть использованы в качестве справочника для изложенного нами материала.

Для кого написана эта книга

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

Среды разработки

Примеры и программы, представленные в этой книге, разработаны и протестированы в Linux- и UNIX-средах, а именно — под управлением Solaris 8, AIX и Linux (SuSE, Red Hat). MPI- и PVM-код разработан и протестирован на 32-узловом Linux-ориентированном кластере. Многие программы протестированы на серверах семейства Sun Enterprise 450. Мы использовали Sun С++ Workshop (С++-компилятор компании Portland Group) и проект по свободному распространению программного обеспечения GNU С ++ . Большинство примеров должны выполняться как в UNIX-, так и Linux-средах. Если конкретный пример не предназначен для выполнения в обеих названных средах, этот факт отмечается в разделе «Профиль программы», которым снабжаются все законченные примеры программ этой книги.

Дополнительный материал

Диаграммы UML

Для построения многих диаграмм в этой книге применяется стандарт UML (Unified Modeling Language-унифицированный язык моделирования). В частности, для описания важных архитектур параллелизма и межклассовых взаимоотношений используются диаграммы действий, развертывания (внедрения), классов и состояний. И хотя знание языка UML не является необходимым условием, все же некоторый уровень осведомленности в этом вопросе окажется весьма полезным. Описание и разъяснение символов и самого языка UML приведено в приложении А .

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

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

Параграфы

Мы посчитали лишним включать сугубо теоретические замечания в такую книгу-введение, как эта. Но в некоторых случаях без теоретических или математических выкладок было не обойтись, и тогда мы сопровождали такие выкладки подробными разъяснениями, оформленными в виде параграфов (например, § 6.1).

Тестирование кода и его надежность

Несмотря на то что все примеры и приложения, приведенные в этой книге, были протестированы для подтверждения их корректности, мы не даем никаких гарантий, что эти программы полностью лишены изъянов или ошибок, совместимы с любым конкретным стандартом, годятся для продажи или отвечают вашим конкретным требованиям. На эти программы не следует полагаться при решении проблем, если существует вероятность, что некорректный способ получения результатов может привести к материальному ущербу. Авторы и издатели этой книги не признают какую бы то ни было ответственность за прямой или косвенный ущерб, который может явиться результатом использования примеров, программ или приложений, представленных в этой книге.

Ждем ваших отзывов!

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

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

Посылая письмо или сообщение, не забудьте указать название книги и ее авторов, а также ваш обратный адрес. Мы внимательно ознакомимся с вашим мнением и обязательно учтем его при отборе и подготовке к изданию последующих книг. Наши координаты:

E-mail:  info@dialektika.com

WWW:  http://www.dialektika.com

Информация для писем из:

России: 115419, Москва, а/я 783

Украины: 03150, Киев, а/я 152

Благодарности

Мы никогда бы не смогли «вытянуть» этот проект без помощи, поддержки, конструктивной критики и материальных ресурсов многих наших друзей и коллег. В частности, мы хотели бы поблагодарить Терри Льюиса (Terry Lewis) и Дага Джонсона (Doug Johnson) из компании OSC (Ohio Super-Computing) за предоставление доступа к 32-узловому Linux-ориентированному кластеру; Марка Уэлтона (Mark Welton) из компании YSU за экспертный анализ и помощь при конфигурировании кластера для поддержки наших PVM- и MPI-программ; Сэлу Сандерс (Sal Sanders) из компании YSU, позволившую нам работать на Power-PC с установленными Mac OSX и Adobe Illustrator; Брайана Нельсона (Brian Nelson) из YSU за разрешение протестировать многие наши многопоточные и распределенные программы на многопроцессорных вычислительных машинах Sun Е-250 и E-450. Мы также признательны Мэри Энн Джонсон (Mary Ann Johnson) и Джеффри Тримблу Qeffrey Trimble) из YSU MAAG за помощь в получении справочной информации; Клавдию M. Стэнзиоло (Claudio M. Stanziola), Полетт Голдвебер (Paulette Goldweber) и Жаклин Хэнсон (Jacqueline Hansson) из объединения IEEE Standards and Licensing and Contracts Office за получение разрешения на переиздание фрагментов нового стандарта Single-UNIX/POSIX; Эндрю Джози (Andrew Josey) и Джину Пирсу (Gene Pierce) из организации Open Group за аналогичное содействие. Большое спасибо Тревору Уоткинсу (Trevor Watkins) из организации Z-Group за помощь в тестировании примеров программ; использование его распределенной Linux-среды было особенно важным фактором в процессе тестирования. Особую благодарность заслужили Стив Тарасвеки (Steve Tarasweki) за согласие написать рецензию на эту книгу (несмотря на то, что она была еще в черновом варианте); доктор Юджин Сантос (Eugene Santos) за то, что он указал нужное направление при составлении категорий структур данных, которые можно использовать в PVM (Parallel Virtual Machine — параллельная виртуальная машина); доктор Майк Кресиманно (Mike Crescimanno) из организации Advanced Computing Work Group (ACWG) при компании YSU за разрешение представить некоторые материалы из этой книги на одном из совещаний ACWG. Наконец, мы хотим выразить признательность Полю Петрелия (Paul Petralia) и всему составу производственной группы (особенно Гейлу Кокеру-Богусу (Gail Cocker-Bogusz)) из компании Prentice Hall за их терпение, поддержку, энтузиазм и высокий профессионализм.

Преимущества параллельного программирования

«Я допускаю, что параллелизм лучше всего поддерживать с помощью библиотеки, причем такую библиотеку можно реализовать без существенных расширений самого языка программирования.»

Бьерн Страуструп, создатель языка С++

Д ля того чтобы в настоящее время разрабатывать программное обеспечение, необходимы практические знания параллельного и распределенного программирования. Теперь перед разработчиками приложений все чаще ставится задача, чтобы отдельные программные составляющие надлежащим образом выполнялись в Internet или Intranet. Если программа (или ее часть) развернута в одной или нескольких таких средах, то к ней предъявляются самые жесткие требования по части производительности. Пользователь всегда надеется, что результаты работы программ будут мгновенными и надежными. Во многих ситуациях заказчик хотел бы, чтобы программное обеспечение удовлетворяло сразу многим требованиям. Зачастую пользователь не видит ничего необычного в своих намерениях одновременно загружать программные продукты и данные из Internet. Программное обеспечение, предназначенное для приема телетекста, также должно быть способно на гладкое воспроизведение графических изображений и звука после цифровой обработки (причем без прерывания). Программное обеспечение Web-сервера нередко выдерживает сотни тысяч посещений в день, а часто посещаемые почтовые серверы— порядка миллиона отправляемых и получаемых сообщений. При этом важно не только количество обрабатываемых сообщений, но и их содержимое. Например, передача данных, содержащих оцифрованные музыку, видео или графические изображения, может «поглотить» всю пропускную способность сети и причинить серьезные неприятности программному обеспечению сервера, которое не было спроектировано должным образом. Обычно мы имеем дело с сетевой вычислительной средой, состоящей из компьютеров с несколькими процессорами. Чем больше функций возлагается на программное обеспечение, тем больше к нему предъявляется требований. Чтобы удовлетворить минимальные требования пользователя, современные программы должны быть еще более производительными и интеллектуальными. Программное обеспечение следует проектировать так, чтобы можно было воспользоваться преимуществами компьютеров, оснащенных несколькими процессорами. А поскольку сетевые компьютеры — это скорее правило, чем исключение, то целью проектирования программного обеспечения должно быть его корректное и эффективное выполнение при условии, что некоторые его составляющие будут одновременно выполняться на различных компьютерах. В некоторых случаях используемые компьютеры могут иметь совершенно различные операционные системы с разными сетевыми протоколами! Чтобы справиться с описанными реалиями, ассортимент разработок программных продуктов должен включать методы реализации параллелизма посредством параллельного и распределенного программирования.

Что такое параллелизм

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

Цель технологий параллелизма — обеспечить условия, позволяющие компьютерным программам делать больший объем работы за тот же интервал времени. Поэтому проектирование программ должно ориентироваться не на выполнение одной задачи в некоторый промежуток времени, а на одновременное выполнение нескольких задач, на которые предварительно должна быть разбита программа. Возможны ситуации, когда целью является не выполнение большего объема работы в течение того же интервала времени, а упрощение решения с точки зрения программирования. Иногда имеет смысл думать о решении проблемы как о множестве параллельно выполняемых задач. Например (если взять для сравнения вполне житейскую ситуацию), проблему снижения веса лучше всего представить в виде двух параллельно выполняемых задач: диета и физическая нагрузка. Иначе говоря, для решения этой проблемы предполагается применение строгой диеты и физических упражнений в один и тот же интервал времени (необязательно точно в одни и те же моменты времени). Обычно не слишком полезно (или эффективно) выполнять одну подзадачу в один период времени, а другую — совершенно в другой. Именно параллельность обоих процессов дает естественную форму искомого решения проблемы. Иногда к параллельности прибегают, чтобы увеличить быстродействие программы или приблизить момент ее завершения. В других случаях параллельность используется для увеличения продуктивности программы (объема выполняемой ею работы) за тот же период времени при вторичности скорости ее работы. Например, для некоторых Web-сайтов важно как можно дольше удерживать пользователей. Поэтому здесь имеет значение не то, насколько быстро будет происходить подключение (регистрация) и отключение пользователей, а сколько пользователей сможет этот сайт обслуживать одновременно. Следовательно, цель проектирования программного обеспечения такого сайта — обрабатывать максимальное количество подключений за как можно больший промежуток времени. Наконец, параллельность упрощает само программное обеспечение. Зачастую сложную последовательность операций можно упростить, организовав ее в виде ряда небольших параллельно выполняемых операций. Независимо от частной цели (ускорение работы программ, обработка увеличенной нагрузки или упрощение реализации программы), наша главная цель — усовершенствовать программное обеспечение, воспользовавшись принципом параллельности.

Два основных подхода к достижению параллельности

Параллельное и распределенное программирование— это два базовых подхода к достижению параллельного выполнения составляющих программного обеспечения (ПО). Они представляют собой две различные парадигмы программирования, которые иногда пересекаются. Методы параллельного программирования позволяют распределить работу программы между двумя (или больше) процессорами в рамках одного физического или одного виртуального компьютера. Методы распределенного программирования позволяют распределить работу программы между двумя (или больше) процессами, причем процессы могут существовать на одном и том же компьютере или на разных. Другими словами, части распределенной программы зачастую выполняются на разных компьютерах, связываемых по сети, или по крайней мере в различных процессах. Программа, содержащая параллелизм, выполняется на одном и том же физическом или виртуальном компьютере. Такую программу можно разбить на процессы (process) или потоки (thread). Процессы мы рассмотрим в главе 3 , а потоки — в главе 4 . В изложении материала этой книги мы будем придерживаться того, что распределенные программы разбиваются только на процессы. Многопоточность ограничивается параллелизмом. Формально параллельные программы иногда бывают распределенными, например, при PVM-программировании ( P arallel V irtual M achine — параллельная виртуальная машина). Распределенное программирование иногда используется для реализации параллелизма, как в случае с MPI-программированием (Message Passing Interface — интерфейс для передачи сообщений). Однако не все распределенные программы включают параллелизм. Части распределенной программы могут выполняться по различным запросам и в различные периоды времени. Например, программу календаря можно разделить на две составляющие. Одна часть должна обеспечивать пользователя информацией, присущей календарю, и способом записи данных о важных для него встречах, а другая часть должна предоставлять пользователю набор сигналов для разных типов встреч. Пользователь составляет расписание встреч, используя одну часть ПО, в то время как другая его часть выполняется независимо от первой. Набор сигналов и компонентов расписания вместе образуют единое приложение, которое разделено на две части, выполняемые по отдельности. При чистом параллелизме одновременно выполняемые части являются компонентами одной и той же программы. Части распределенных приложений обычно реализуются как отдельные программы. Типичная архитектура построения параллельной и распределенной программ показана на рис. 1.1.

Рис 1.1 Типичная архитектура построения параллельной и распределенной программ

Параллельное приложение, показанное на рис. 1.2, состоит из одной программы, разделенной на четыре задачи. Каждая задача выполняется на отдельном процессоре, следовательно, все они могут выполняться одновременно. Эти задачи можно реализовать в 1.2, состоит из трех отдельных программ, каждая из которых выполняется на отдельном компьютере [3]. При этом программа 3 состоит из двух отдельных частей (задачи А и задачи D), выполняющихся на одном компьютере. Несмотря на это, задачи А и D являются распределенными, поскольку они реализованы как два отдельных процесса. Задачи параллельной программы более тесно связаны, чем задачи распределенного приложения. В общем случае процессоры, связанные с распределенными программами, находятся на различных компьютерах, в то время как процессоры, связанные с программами, реализующими параллелизм, находятся на одном и том же компьютере. Конечно же, существуют гибридные приложения, которые являются и параллельными, и распределенными одновременно. Именно такие гибридные объединения становятся нормой.

Преимущества параллельного программирования

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

Простейшая модель параллельного программирования (PRAM)

В качестве простейшей модели, отражающей базовые концепции параллельного программирования, рассмотрим модель PRAM (Parallel Random Access Machine — параллельная машина с произвольным доступом). PRAM — это упрощенная теоретическая модель с n процессорами, которые используют общую глобальную память. Простая модель PRAM изображена на рис. 1.2.

Рис 1-2 Простая модель PRAM

Все процессоры имеют доступ для чтения и записи к общей глобальной памяти. В PRAM-среде возможен одновременный доступ. Предположим, что все процессоры могут параллельно выполнять различные арифметические и логические операции. Кроме того, каждый из теоретических процессоров (см. рис. 1.2) может обращаться к общей памяти в одну непрерываемую единицу времени. PRAM-модель обладает как параллельными, так и исключающими алгоритмами считывания данных. Параллельные алгоритмы считывания данных позволяют одновременно обращаться к одной и той же области памяти без искажения (порчи) данных. Исключающие алгоритмы считывания данных используются в случае, когда необходима гарантия того, что никакие два процесса никогда не будут считывать данные из одной и той же области памяти одновременно. PRAM-модель также обладает параллельными и исключающими алгоритмами записи данных. Параллельные алгоритмы позволяют нескольким процессам одновременно записывать данные в одну и ту же область памяти, в то время как исключающие алгоритмы гарантируют, что никакие два процесса не будут записывать данные в одну и ту же область памяти одновременно. Четыре основных алгоритма считывания и записи данных перечислены в табл. 1.1.

Таблица 1.1. Четыре базовых алгоритма считывания и записи данных

EREW Исключающее считывание/исключающая запись

CREW Параллельное считывание/исключающая запись

ERCW Исключающее считывание/параллельная запись

CRCW Параллельное считывание/параллельная запись

В этой книге мы будем часто обращаться к этим типам алгоритмов для реализации параллельных архитектур. Архитектура, построенная на основе технологии «классной доски», — это одна из важных архитектур, которую мы реализуем с помощью PRAM-м одели (см. главу 13). Необходимо отметить, что хотя PRAM — это упрощенная теоретическая модель, она успешно используется для разработки практических программ, и эти программы могут соперничать по производительности с программами, которые были разработаны с использованием более сложных моделей параллелизма.

Простейшая классификация схем параллелизма

PRAM — это способ построения простой модели, которая позволяет представить, как компьютеры можно условно разбить на процессоры и память и как эти процессоры получают доступ к памяти. Упрощенная классификации схем функционирования параллельных компьютеров была предложена M. Флинном (M.J. Flynn) [4] . Согласно этой классификации различались две схемы: SIMD (Single-Instruction, Multiple-Data — архитектура с одним потоком команд и многими потоками данных) и MIMD (Multiple-Instruction, Multiple-Data — архитектура со множеством потоков команд и множеством потоков данных). Несколько позже эти схемы были расширены до SPMD (Single-Program, Multiple-Data — одна программа, несколько потоков данных) и MPMD (Multiple-Programs, Multiple-Data — множество программ, множество потоков данных) соответственно. Схема SPMD (SIMD) позволяет нескольким процессорам выполнять одну и ту же инструкцию или программу при условии, что каждый процессор получает доступ к различным данным. Схема MPMD (MIMD) позволяет работать нескольким процессорам, причем все они выполняют различные программы или инструкции и пользуются собственными данными. Таким образом, в одной схеме все процессоры выполняют одну и ту же программу или инструкцию, а в другой все процессоры выполняют различные программы или инструкции. Конечно же, возможны гибриды этих моделей, в которых процессоры могут быть разделены на группы, из которых одни образуют SPMD-модель, а другие — MPMD-модель. При использовании схемы SPMD все процессоры просто выполняют одни и те же операции, но с различными данными. Например, мы можем разбить одну задачу на группы и назначить для каждой группы отдельный процессор. В этом случае каждый процессор при решении задачи будет применять одинаковые правила, обрабатывая при этом различные части этой задачи. Когда все процессоры справятся со своими участками работы, мы получим решение всей задачи. Если же применяется схема MPMD, все процессоры выполняют различные виды работы, и, хотя при этом все они вместе пытаются решить одну проблему, каждому из них выделяется свой аспект этой проблемы. Например, разделим задачу по обеспечению безопасности Web-сервера по схеме MPMD. В этом случае каждому процессору ставится своя подзадача. Предположим, один процессор будет отслеживать работу портов, другой — курировать процесс регистрации пользователей, а третий — анализировать содержимое пакетов и т.д. Таким образом, каждый процессор работает с нужными ему данными. И хотя различные процессоры выполняют разные виды работы, используя различные данные, все они вместе работают в одном направлении — обеспечивают безопасность Web-сервера. Принципы параллельного программирования, рассматриваемые в этой книге, нетрудно описать, используя модели PRAM, SPMD (SIMD) и MPMD (MIMD). И в самом деле, эти схемы и модели успешно используются для реализации практических мелко- и среднемасштабных приложений и вполне могут вас устраивать до тех пор, пока вы не подготовитесь к параллельному программированию более высокой степени организации.

Преимущества распределенного программирования

Методы распределенного программирования позволяют воспользоваться преимуществами ресурсов, размещенных в Internet, в корпоративных Intranet и локальных сетях. Распределенное программирование обычно включает сетевое программирование в той или иной форме. Это означает, что программе, которая выполняется на одном компьютере в одной сети, требуется некоторый аппаратный или программный ресурс, который принадлежит другому компьютеру в той же или удаленной сети. Распределенное программирование подразумевает общение одной программы с другой через сетевое соединение, которое включает соответствующее оборудование (от модемов до спутников). Отличительной чертой распределенных программ является то, что они разбиваются на части. Эти части обычно реализуются как отдельные программы, которые, как правило, выполняются на разных компьютерах и взаимодействуют друг с другом через сеть. Методы распределенного программирования предоставляют доступ к ресурсам, которые географически могут находиться на большом расстоянии друг от друга. Например, распределенная программа, разделенная на компонент Web-сервера и компонент Web-клиента, может выполняться на двух различных компьютерах. Компонент Web-се pвepa может располагаться, допустим, в Африке, а компонент Web-клиента — в Японии. Часть Web-клиента может использовать программные и аппаратные ресурсы компонента Web-сервера, несмотря на то, что их разделяет огромное расстояние, и почти наверняка они относятся к различным сетям, функционирующим под управлением различных операционных сред. Методы распределенного программирования предусматривают совместный доступ к дорогостоящим программным и аппаратным ресурсам. Например, высококачественный голографический принтер может обладать специальным программным обеспечением сервера печати, которое предоставляет соответствующие услуги для ПО клиента. ПО клиента печати размещается на одном компьютере, а ПО сервера печати — на другом. Как правило, для обслуживания множества клиентов печати достаточно только одного сервера печати. Распределенные вычисления можно использовать для создания определенного уровня избыточности вычислительных средств на случай аварии. Если разделить программу на несколько частей, каждая из которых будет выполняться на отдельном компьютере, то некоторым из этих частей мы можем поручить одну и ту же работу. Если по какой-то причине один компьютер откажет, его программу заменит аналогичная программа, выполняющаяся на другом компьютере. Ни для кого не секрет, что базы данных способны хранить миллионы, триллионы и даже квадриллионы единиц информации. И, конечно же, нереально каждому пользователю иметь копию подобной базы данных. А ведь пользователи и компьютер, содержащий базу данных, зачастую находятся не просто в разных зданиях, а в разных городах или даже странах. Но именно методы распределенного программирования дают возможность пользователям (независимо от их местонахождения) обращаться к таким базам данных.

Простейшие модели распределенного программирования

Возможно, самой простой и распространенной моделью распределенной обработки данных является модель типа «клиент/сервер». В этой модели программа разбивается на две части: одна часть называется сервером, а другая — клиентом. Сервер имеет прямой доступ к некоторым аппаратным и программным ресурсам, которые желает использовать клиент. В большинстве случаев сервер и клиент располагаются на разных компьютерах. Обычно между клиентом и сервером существует отношение типа «множество-к-одному», т.е., как правило, один сервер отвечает на запросы многих клиентов. Сервер часто обеспечивает опосредованный доступ к огромной базе данных, дорогостоящему оборудованию или некоторой коллекции приложений. Клиент может запросить интересующие его данные, сделать запрос на выполнение вычислительной процедуры или обработку другого типа. В качестве примера приложения типа «клиент/сервер» приведем механизм поиска (search engine). Механизмы (или машины) поиска используются для поиска заданной информации в Internet или корпоративной Intranet. Клиент служит для получения ключевого слова или фразы, которая интересует пользователя. Часть ПО клиента затем передает сформированный запрос той части ПО сервера, которая обладает средствами поиска информации по заданному пользователем ключевому слову или фразе. Сервер либо имеет прямой доступ к информации, либо связан с другими серверами, которые имеют его. В идеальном случае сервер находит запрошенное пользователем ключевое слово или фразу и возвращает найденную информацию клиенту. Несмотря на то что клиент и сервер представляют собой отдельные программы, выполняющиеся на разных компьютерах, вместе они составляют единое приложение. Разделение ПО на части клиента и сервера и есть основной метод распределенного программирования. Модель типа «клиент/сервер» также имеет другие формы, которые зависят от конкретной среды. Например, термин «изготовитель-потребитель» (producer-consumer) можно считать близким родственником термина «клиент/сервер». Обычно клиент-серверными приложениями называют большие программы, а термин «изготовитель-потребитель» относят к программам меньшего объема. Если программы имеют уровень операционной системы или ниже, к ним применяют термин «изготовитель-потребитель», если выше — то термин «клиент/сервер» (конечно же, исключения есть из всякого правила).

Мультиагентные распределенные системы

Несмотря на то что модель типа «клиент/сервер» — самая распространенная модель распределенного программирования, все же она не единственная. Используются также агенты — рациональные компоненты ПО, которые характеризуются самонаведением и автономностью и могут постоянно находиться в состоянии выполнения. Агенты могут как создавать запросы к другим программным компонентам, так и отвечать на запросы, полученные от других программных компонентов. Агенты сотрудничают в пределах групп для коллективного выполнения определенных задач. В такой модели не существует конкретного клиента или сервера. Это — модель сети с равноправными узлами (peer-to-peer), в которой все компоненты имеют одинаковые права, и при этом у каждого компонента есть что предложить другому. Например, агент, который назначает цены на восстановление старинных спортивных машин, может работать вместе с другими агентами. Один агент может быть специалистом по моторам, другой — по кузовам, а третий предпочитает работать как дизайнер по интерьерам. Эти агенты могут совместно оценить стоимость работ по восстановлению автомобиля. Агенты являются распределенными, поскольку все они размещаются на разных серверах в Internet. Для связи агенты используют согласованный Internet-протокол. Для одних типов распределенного программирования лучше подходит модель типа «клиент/сервер», а для других — модель равноправных агентов. В этой книге рассматриваются обе модели. Большинство требований, предъявляемых к распределенному программированию, удовлетворяется моделями «клиент/сервер» и равноправных агентов.

Минимальные требования

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

Декомпозиция

Декомпозиция — это процесс разбиения задачи и ее решения на части. Иногда части группируются в логические области (т.е. поиск, сортировка, вычисление, ввод и вывод данных и т.д.). В других случаях части группируются по логическим ресурсам (т.е. файл, связь, принтер, база данных и т.д.). Декомпозиция программного решения часто сводится к декомпозиции работ (work breakdown structure — WBS). Декомпозиция работ определяет, что должны делать разные части ПО. Одна из основных проблем параллельного программирования — идентификация естественной декомпозиции работ для программного решения. Не существует простого и однозначного подхода к идентификации WBS. Разработка ПО — это процесс перевода принципов, идей, шаблонов, правил, алгоритмов или формул в набор инструкций, которые выполняются, и данных, которые обрабатываются компьютером. Это, в основном, и составляет процесс моделирования. Программные модели — это воспроизведение в виде ПО некоторой реальной задачи, процесса или идеала. Цель модели— сымитировать или скопировать поведение и характеристики некоторой реальной сущности в конкретной предметной области. Процесс моделирования вскрывает естественную декомпозицию работ программного решения. Чем лучше модель понята и разработана, тем более естественной будет декомпозиция работ. Наша цель — обнаружить параллелизм и распределение с помощью моделирования. Если естественный параллелизм не наблюдается, не стоит его навязывать насильно. На вопрос, как разбить приложение на параллельно выполняемые части, необходимо найти ответ в период проектирования, и правильность этого ответа должна стать очевидной в модели решения. Если модель задачи и решения не предполагает параллелизма и распределения, следует попытаться найти последовательное решение. Если последовательное решение оказывается неудачным, эта неудача может дать ключ к нужному параллельному решению.

Связь

После декомпозиции программного решения на ряд параллельно выполняемых частей обычно возникает вопрос о связи этих частей между собой. Как же реализовать связь, если эти части разнесены по различным процессам или различным компьютерам? Должны ли различные части ПО совместно использовать общую область памяти? Каким образом одна часть ПО узнает о том, что другая справилась со своей задачей? Какая часть должна первой приступить к работе? Откуда один компонент узнает об отказе другого компонента? На эти и многие другие вопросы необходимо найти ответы при проектировании параллельных и распределенных систем. Если отдельным частям ПО не нужно связываться между собой, значит, они в действительности не образуют единое приложение.

Синхронизация

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

Базовые уровни программного параллелизма

В этой книге мы исследуем возможности параллелизма в пределах приложения (в противоположность параллелизму на уровне операционной системы или аппаратных средств). Несмотря на то что параллелизм на уровне операционной системы или аппаратных средств поддерживает параллелизм приложения, нас все же интересует само приложение. Итак, параллелизм можно обеспечить на уровне:

• инструкций;

• подпрограмм (функций или процедур);

• объектов;

• приложений.

Параллелизм на уровне инструкций

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

На рис. 1.3 компонент (А + В) можно вычислить одновременно с компонентом (С - D) • Этот вид параллелизма обычно поддерживается директивами компилятора и не попадает под управление С++-программиста.

Рис. 1.3. Декомпозиция одной инструкции

Параллелизм на уровне подпрограмм

ДСС структуру программы можно представить в виде ряда функций, т.е. сумма работ, из которых состоит программное решение, разбивается на некоторое количество функций. Если эти функции распределить по потокам, то каждую функцию в этом случае можно выполнить на отдельном процессоре, и, если в вашем распоряжении будет достаточно процессоров, то все функции смогут выполняться одновременно. Подробнее потоки описываются в главе 4.

Параллелизм на уровне объектов

ДСС-структуру программного решения можно распределить между объектами. Каждый объект можно назначить отдельному потоку или процессу. Используя стандарт CORBA (Common Object Request Broker Architecture — технология построения распределенных объектных приложений), все объекты можно назначить различным компьютерам одной сети или различным компьютерам различных сетей. Более детально технология CORBA рассматривается в главе 8. Объекты, реализованные в различных потоках или процессах, могут выполнять свои методы параллельно.

Параллелизм на уровне приложений

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

Второй и третий уровни — это основные уровни параллелизма, поэтому методам их реализации и уделяется основное внимание в этой книге. Уровня операционной системы и аппаратных средств мы коснемся только в том случае, когда это будет необходимо в контексте проектирования приложений. Получив соответствующую ДСС-структуру для проекта, предусматривающего параллельное или распределенное программирование, можно переходить к следующему этапу — рассмотрению возможности его реализации в С++.

Отсутствие языковой поддержки параллелизма в С++

Язык С++ не содержит никаких синтаксических примитивов для параллелизма. С++-стандарт ISO также отмалчивается на тему многопоточности. В языке С++ не предусмотрено никаких средств, чтобы указать, что заданные инструкции должны выполняться параллельно. Включение встроенных средств параллелизма в других языках представляется как их особое достоинство. Бьерн Страуструп, создатель языка С++, имел свое мнение на этот счет:

Можно организовать поддержку параллелизма средствами библиотек, которые будут приближаться к встроенным средствам параллелизма как по эффективности, так и по удобству применения. Опираясь на такие библиотеки, можно поддерживать различные модели, а не только одну, как при использования встроенных средств параллелизма. Я полагаю, что большинство программистов согласятся со мной, что именно такое направление (создание набора библиотек поддержки параллелизма) позволит решить проблемы переносимости, используя тонкий слой интерфейсных классов.

Более того, Страуструп говорит: « Я считаю, что параллелизм в С++ должен быть представлен библиотеками, а не как языковое средство» . Авторы этой книги находят позицию Страуструпа и его рекомендации по реализации параллелизма в качестве библиотечного средства наиболее подходящими с практической точки зрения. В настоящей книге рассмотрен только этот вариант, и такой выбор объясняется доступностью высококачественных библиотек, которые успешно можно использовать для решения задач параллельного и распределенного программирования. Библиотеки, которые мы используем для усиления языка С++ с этой целью, реализуют национальные и международные стандарты и используются тысячами С++-программистов во всем мире.

Варианты реализации параллелизма с помощью С++

Несмотря на существование специальных версий языка С++, предусматривающих «встроенные» средства параллельной обработки данных, мы представляем методы реализации параллелизма с использованием стандарта ISO (International Organization for Standardization — Международная организация по стандартизации) для С++. Мы находим библиотечный подход к параллелизму (при котором используются как системные, так и пользовательские библиотеки) наиболее гибким. Системные библиотеки предоставляются средой операционной системы. Например, поточно-ориентированная библиотека POSIX (Portable Operating System Interface — интерфейс переносимой операционной системы) содержит набор системных функций, которые в сочетании с языковыми средствами С++ успешно используются для поддержки параллелизма. Библиотека POSIX Threads является частью нового единого стандарта спецификаций UNIX (Single UNIX Specifications Standard) и включена в набор стандартов IEEE, описывающих интерфейсы ОС для UNIX (IEEE Std. 1003.1-2001). Создание нового единого стандарта спецификаций UNIX финансируется организацией Open Group, а его разработка поручена организации Austin Common Standards Revision Group. В соответствии с документами Open Group новый единый стандарт спецификаций UNIX:

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

• смещает акцент с несовместимых реализаций систем UNIX на соответствие единому набору функций API;

• представляет собой кодификацию и юридическую стандартизацию общего ядра системы UNIX;

• в качестве основной цели преследует достижение переносимости исходного кода приложения.

Новый единый стандарт спецификаций UNIX, версия 3, включает стандарт IEEE Std. 1003.1-2001 и спецификации Open Group Base Specifications Issue 6. Стандарты IEEE POSIX в настоящее время представляют собой часть единой спецификации UNIX, и наоборот. Сейчас действует единый международный стандарт для интерфейса переносимой операционной системы. С++-разработчикам это только на руку, поскольку данный стандарт содержит API-функции, которые позволяют создавать потоки и процессы. За исключением параллелизма на уровне инструкций, единственным способом достижения параллелизма с помощью С++ является разбиение программы на потоки или процессы. Именно эти средства и предоставляет новый стандарт. Разработчик может использовать:

• библиотеку POSIX Threads (или Pthreads);

• POSIX-версию spawn ();

• семейство функций exec ().

Все эти средства поддерживаются системными API-функциями и системными библиотеками. Если операционная система отвечает 3-й версии нового единого стандарта UNIX, то С++-разработчику будут доступны эти API-функции (они рассматриваются в главах З и 4 и используются во многих примерах этой книги). Помимо библиотек системного уровня, для поддержки параллелизма в С++ могут применяться такие библиотеки пользовательского уровня, как MPI (Message Passing Interface — интерфейс для передачи сообщений), PVM (Parallel Virtual Machine — параллельная виртуальная машина) и CORBA (Common Object Request Broker Architecture — технология построения распределенных объектных приложений).

Стандарт MPI

Интерфейс MPI — стандартная спецификация на передачу сообщений — был разработан с целью достижения высокой производительности на компьютерах с массовым параллелизмом и кластерах рабочих станций (рабочая станция — это сетевой компьютер, использующий ресурсы сервера). В этой книге используется MPICH-реализация стандарта MPI. MPICH — это свободно распространяемая переносимая реализация интерфейса MPI. MPICH предоставляет С++-программисту набор API-функций и библиотек, которые поддерживают параллельное программирование. Интерфейс MPI особенно полезен для программирования моделей SPMD (Single-Program, Multiple Data - одна программа , несколько потоков данных) и MPMD (Multiple-Program, Multiple-Data — множество программ, множество потоков данных). Авторы этой книги используют MPICH-реализацию библиотеки MPI для 32-узлового Linux-ориентированного кластера и 8-узлового кластера, управляемого операционными системами Linux и Solaris. И хотя в С++ нет встроенных примитивов параллельного программирования, С++-программист может воспользоваться средствами обеспечения параллелизма, предоставляемыми библиотекой MPICH. В этом и состоит одно из достоинств языка С++, которое заключается в его фантастической гибкости.

PVM: стандарт для кластерного программирования

Программный пакет PVM позволяет связывать гетерогенную (неоднородную) коллекцию компьютеров в сеть для использования ее в качестве единого мощного параллельного компьютера. Общая цель PVM-системы — получить возможность совместно использовать коллекцию компьютеров для организации одновременной или параллельной обработки данных. Реализация библиотеки PVM поддерживает:

• гетерогенность по компьютерам, сетям и приложениям;

• подробно разработанную модель передачи сообщений;

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

• мультипроцессорную обработку данных (MPP, SMP) [5];

• «полупрозрачный» доступ к оборудованию (т.е. приложения могут либо игнорировать, либо использовать преимущества различий в аппаратных средствах);

• динамически настраиваемый пул (процессоры могут добавляться или удаляться динамически, возможен также их смешанный состав).

PVM — это самая простая (по использованию) и наиболее гибкая среда, доступная для решения задач параллельного программирования, которые требуют применения различных типов компьютеров, работающих под управлением различных операционных систем. PVM-библиотека особенно полезна для объединения в сеть нескольких однопроцессорных систем с целью образования виртуальной машины с параллельно работающими процессорами. Методы использования библиотеки PVM в С++-коде мы рассмотрим в главе 6. PVM — это фактический стандарт для реализации гетерогенных кластеров, который легко доступен и широко распространен. PVM прекрасно поддерживает модели параллельного программирования MPMD (MIMD) и SPMD (SIMD). Авторы этой книги для решения небольших и средних по объему задач параллельного программирования используют PVM-библиoтeкy, а для более сложных и объемных — MPI-библиотеку. Обе библиотеки PVM и MPI можно успешно сочетать с С++ для программирования кластеров.

Стандарт CORBA

CORBA— это стандарт для распределенного кроссплатформенного объектно-ориентированного программирования. Выше упоминалось о применении CORBA для поддержки параллелизма, поскольку реализации стандарта CORBA можно использовать для разработки мультиагентных систем. Мультиагентные системы предлагают важные сетевые модели распределенного программирования с равноправными узлами (peer-to_peer). В мультиагентных системах работа может быть организована параллельно. Это одна из областей, в которых параллельное и распределенное программирование перекрываются. Несмотря на то что агенты выполняются на различных компьютерах, это происходит в течение одного и того же промежутка времени, т.е. агенты совместно работают над общей проблемой. Стандарт CORBA обеспечивает открытую, независимую от изготовителя архитектуру и инфраструктуру, которую компьютерные приложения используют для совместного функционирования в сети. Используя стандартный протокол IIOР (Internet InterORB Protocol — протокол, определяющий передачу сообщений между сетевыми объектами по TCP/IP), CORBA-ориентированная программа (созданная любым производителем на любом языке программирования, выполняемая практически на любом компьютере под управлением любой операционной системы в любой сети) может взаимодействовать с другой CORBA-ориентированной программой (созданной тем же или другим производителем на любом другом языке программирования, выполняемой практически на любом компьютере под управлением любой операционной системы в любой сети). В этой книге мы используем MICO-реализацию стандарта CORBA. MICO— свободно распространяемая и полностью соответствующая требованиям реализация стандарта CORBA, которая поддерживает язык С++.

Реализации библиотек на основе стандартов

Библиотеки MPICH, PVM, MICO и POSIX Threads реализованы на основе стандартов. Это означает, что разработчики ПО могут быть уверены, что эти реализации широко доступны и переносимы с одной платформы на другую. Эти библиотеки используются многими разработчиками ПО во всем мире. Библиотеку POSIX Threads можно использовать с С++ для реализации многопоточного программирования. Если программа выполняется на компьютере с несколькими процессорами, то каждый поток может выполняться на отдельном процессоре, что позволяет говорить о реальной параллельности программирования. Если же компьютер содержит только один процессор, то иллюзия параллелизма обеспечивается за счет процесса переключения контекстов. Библиотека POSIX Threads позволяет реализовать, возможно, самый простой способ введения параллелизма в С++-программу. Если для использования библиотек MPICH, PVM и MICO необходимо предварительно побеспокоиться об их установке, то в отношении библиотеки POSIX Threads это излишне, поскольку среда любой операционной системы, которая согласована с POSIX-стандартом или новой спецификацией UNDC (версия 3), оснащена реализацией библиотеки POSIX Threads. Все библиотеки предлагают модели параллелизма, которые имеют незначительные различия. В табл. 1.2 показано, как каждую библиотеку можно использовать с С++.

Таблица 1.2. Использование библиотек MPICH, PVM, MICO и POSIX Threads с С++

MPICH  Поддерживает крупномасштабное сложное программирование кластеров. Предпочтительно используется для модели SPMD. Также поддерживает SMP-, MPP- и многопользовательские конфигурации

PVM Поддерживает кластерное программирование гетерогенных сред. Легко

используется для однопользовательских (мелко- и среднемасштабных) ._____кластерных приложений. Также поддерживает МРР-конфигурации .

MICO Поддерживает и распределенное, и параллельное программирование.

Содержит эффективные средства поддержки агентно-ориентированного и мультиагентного программирования

POSIX Поддерживает параллельную обработку данных в одном приложении на

уровне функций или объектов. Позволяет воспользоваться преимуществами SMP- и МРР-конфигурации

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

Среды для параллельного и распределенного программирования

Наиболее распространенными средами для параллельного и распределенного программирования являются кластеры, SMP- и МРР-компьютеры.

Кластеры — это коллекции, состоящие из нескольких компьютеров, объединенных сетью для создания единой логической системы. С точки зрения приложения такая группа компьютеров выглядит как один виртуальный компьютер. Под MPP-конфигурацией (Massively Parallel Processors — процессоры с массовым параллелизмом) понимается один компьютер, содержащий сотни процессоров, а под SMP-конфигурацией (symmetric multiprocessor — симметричный мультипроцессор) — единая система, в которой тесно связанные процессоры совместно используют общую память и информационный канал. SMP-процессоры разделяют общие ресурсы и являются объектами управления одной операционной системы. Поскольку эта книга представляет собой введение в параллельное и распределенное программирование, нас будут интересовать небольшие кластеры, состоящие из 8-32 процессоров, и многопроцессорные компьютеры с двумя-четырьмя процессорами. И хотя многие рассматриваемые здесь методы можно использовать в MPP- или больших SMP-средах, мы в основном уделяем внимание системам среднего масштаба.

Резюме

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

Проблемы параллельного и распределенного программирования

«Стремление обозначать точные значения любой физической величины (температура, плотность, напряженность потенциального поля или что-либо еще...) есть не что иное как смелая экстраполяция.»

Эрвин Шредингер (Erwin Shrodinger), Causality and Wave Mechanics

В базовой последовательной модели программирования инструкции компьютерной программы выполняются поочередно. Программа выглядит как кулинарный рецепт, в соответствии с которым для каждого действия компьютера задан порядок и объемы используемых «ингредиентов». Разработчик программы разбивает основную задачу ПО на коллекцию подзадач. Все задачи выполняются по порядку, и каждая из них должна ожидать своей очереди. Все программы имеют начало, середину и конец. Разработчик представляет каждую программу в виде линейной последовательности задач. Эти задачи необязательно должны находиться в одном файле, но их следует связать между собой так, чтобы, если первая задача по какой-то причине не завершила свою работу, то вторая вообще не начинала выполнение. Другими словами, каждая задача, прежде чем приступить к своей работе, должна ожидать до тех пор, пока не получит результатов выполнения предыдущей. В последовательной модели зачастую устанавливается последовательная зависимость задач. Это означает, что задаче А необходимы результаты выполнения задачи В, а задаче В нужны результаты выполнения задачи С, которой требуется что-то от задачи D и т.д. Если при выполнении задачи В по какой-то причине произойдет сбой, задачи С и D никогда не п риступят к работе. В таком последовательном мире разработчик привычно ориентирует ПО сначала на выполнение действия 1, затем — действия 2, за которым должно следовать действие 3 и т.д. Подобная последовательная модель настолько закрепилась в процессе проектирования и разработки ПО, что многие программисты считают ее незыблемой и не допускают мысли о возможности иного положения вещей. Решение каждой проблемы, разработка каждого алгоритма и планирование каждой структуры данных — все это делалось с мыслью о последовательном доступе компьютера к каждой инструкции или ячейке данных.

Кардинальное изменение парадигмы

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

Рис. 2.1. Три уровня параллелизма, которые возможны в одной компьютерной программе

Модель программы, показанная на рис. 2.1, отражает кардинальное изменение парадигмы программирования, которая была характерна для «раннего» сознания программистов и разработчиков. Здесь отображены три уровня параллелизма и их распределение по нескольким процессорам. Сочетание этих трех уровней с базовыми параллельными конфигурациями процессоров показано на рис. 2.2.

Рис. 2.2. Три уровня параллелизма в сочетании с конфигурациями процессоров базовыми параллельными

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

Проблемы координации

Если программа содержит подпрограммы, которые могут выполняться параллельно, и эти подпрограммы совместно используют некоторые файлы, устройства или области памяти, то неизбежно возникают проблемы координации. Предположим, у нас есть программа поддержки электронного банка, которая позволяет снимать деньги со счета и класть их на депозит. Допустим, что эта программа разделена на три задачи (обозначим их А, В и С), которые могут выполняться параллельно.

Задача А получает запросы от задачи В на выполнение операций снятия денег со счета. Задача А также получает запросы от задачи С положить деньги на депозит. За-Дача А принимает запросы и обрабатывает их по принципу «первым пришел — первым обслужен». Предположим, на счете имеется 1000 долл., при этом задача С требует положить на депозит 100 долл., а задача В желает снять со счета 1100 долл. Что произойдет, если обе задачи В и С попытаются обновить один и тот же счет одновременно?

Каким будет остаток на счете? Очевидно, остаток на счете в каждый момент времени не может иметь более одного значения. Задача А применительно к счету должна выполнять одновременно только одну транзакцию, т.е. мы сталкиваемся с проблемой координации задач. Если запрос задачи В будет выполнен на какую-то долю секунды быстрее, чем запрос задачи С, то счет приобретет отрицательный баланс. Но если задача С получит первой право на обновление счета, то этого не произойдет. Таким образом, остаток на счете зависит от того, какой задаче (В или С) первой удастся сделать запрос к задаче А. Более того, мы можем выполнять задачи В и С несколько раз с одними и теми же значениями, и при этом иногда запрос задачи В будет произведен на какую-то долю секунды быстрее, чем запрос задачи С, а иногда — наоборот. Очевидно, что необходимо организовать надлежащую координацию действий.

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

Проблема № 1 : «гонка» данных

Если несколько задач одновременно попытаются изменить некоторую общую область данных, а конечное значение данных при этом будет зависеть от того, какая задача обратится к этой области первой, возникнет ситуация, которую называют состоянием «гонок» (race condition). В случае, когда несколько задач попытаются обновить один и тот же ресурс данных, такое состояние «гонок» называют «гонкой»данных (data race). Какая задача в нашей программе поддержки электронного банка первой получит доступ к остатку на счете, определяется результатом работы планировщика задач операционной системы, состоянием процессоров, временем ожидания и случайными причинами. В такой ситуации создается состояние «гонок». И какое значение в этом случае должен сообщать банк в качестве реального остатка на счете?

Итак, несмотря на то, что мы хотели бы, чтобы наша программа позволяла одновременно обрабатывать множество операций по снятию денег со счета и вложению их на депозит, нам нужно координировать эти задачи в случае, если окажется, что операции снятия и вложения денег должны быть применены к одному и тому же счету. Всякий раз когда задачи одновременно используют модифицируемый ресурс, к ресурсному доступу этих задач должны быть применены определенные правила и стратегии. Например, в нашей программе поддержки банковских операций со счетами мы могли бы всегда выполнять любые операции по вложению денег до выполнения каких бы то ни было операций по их снятию. Мы могли бы установить правило, в соответствии с которым доступ к счету одновременно могла получать только одна транзакция. И если окажется, что к одному и тому же счету одновременно обращается сразу несколько транзакций, их необходимо задержать, организовать их выполнение в соответствии с некоторым правилом очередности, а затем предоставлять им доступ к счету по одной (в порядке очереди). Такие правила организации позволяют добиться надлежащей синхронизации действий.

Проблема № 2: бесконечная отсрочка

Такое планирование, при котором одна или несколько задач должны ожидать до тех пор, пока не произойдет некоторое событие или не создадутся определенные условия, м ожет оказаться довольно непростым для реализации. Во-первых, ожидаемое событие или условие должно отличаться регулярностью. Во-вторых, между задачами следует наладить связи. Если одна или несколько задач ожидают сеанса связи до своего выполнения, то в случае, если ожидаемый сеанс связи не состоится, состоится слишком поздно или не полностью, эти задачи могут так никогда и не выполниться. И точно так же, если ожидаемое событие или условие, которое (по нашему мнению) должно произойти (или наступить), но в действительности не происходит (или не наступает), то приостановленные нами задачи будут вечно находиться в состоянии ожидания. Если мы приостановим одну или несколько задач до наступления события (или условия), которое никогда не произойдет, возникнет ситуация, называемая бесконечной отсрочкой (indefinite postponement). Возвращаясь к нашему примеру электронного банка, предположим, что, если мы установим правила, предписывающие всем задачам снятия денег со счета находиться в состоянии ожидания до тех пор, пока не будут выполнены все задачи вложения денег на счет, то задачи снятия денег рискуют стать бесконечно отсроченными.

Мы исходили из предположения о гарантированном существовании задач вложения денег на счет. Но если ни один из запросов на пополнение счетов не поступит, то что тогда заставит выполниться задачи снятия денег? И, наоборот, что, если будут без конца поступать запросы на пополнение одного и того же счета? Ведь тогда не сможет «пробиться» к счету ни один из запросов на снятие денег. Такая ситуация также может вызвать бесконечную отсрочку задач снятия денег.

Бесконечная отсрочка возникает при отсутствии задач вложения денег на счет или их постоянном поступлении. Необходимо также предусмотреть ситуацию, когда запросы на вложение денег поступают корректно, но нам не удается надлежащим образом организовать связь между событиями и задачами. По мере того как мы будем пытаться скоординировать доступ параллельных задач к некоторому общему ресурсу данных, следует предусмотреть все ситуации, в которых возможно создание бесконечной отсрочки. Методы, позволяющие избежать бесконечных отсрочек, рассматриваются в главе 5.

Проблема №3: взаимоблокировка

Взаимоблокировка — это еще одна «ловушка», связанная с ожиданием. Для демонстрации взаимоблокировки предположим, что в нашей программе поддержки электронного банка три задачи работают не с одним, а с двумя счетами. Вспомним, что задача А получает запросы от задачи В на снятие денег со счета, а от задачи С — запросы на вложение денег на депозит. Задачи А, В и С могут выполняться параллельно. Однако задачи В и С могут обновлять одновременно только один счет. Задача А предоставляет доступ задач В и С к нужному счету по принципу «первым пришел — первым обслужен». Предположим также, что задача В имеет монопольный доступ к счету 1, а задача С — монопольный доступ к счету 2. При этом задаче В для выполнения соответствующей обработки также нужен доступ к счету 2 и задаче С — доступ к счету 1. Задача В удерживает счет 1, ожидая, пока задача С не освободит счет 2. Аналогично задача С удерживает счет 2, ожидая, пока задача В не освободит счет 1. Тем самым задачи В и С рискуют попасть в тупиковую ситуацию , которую в данном случае можно назвать взаимоблокировкой (deadlock). Ситуация взаимоблокировки между задачами В и С схематично показана на рис. 2.3.

Форма взаимоблокировки в данном случае объясняется наличием параллельно выполняемых задач, имеющих доступ к совместно используемым данным, которые им разрешено обновлять. Здесь возможна ситуация, когда каждая из задач будет ожидать до тех пор, пока другая не освободит доступ к общим данным (общими данными здесь являются счет 1 и счет 2). Обе задачи имеют доступ к обоим счетам. Может случиться так,

вместо получения доступа одной задачи к двум счетам, каждая задача получит доступ одному из счетов. Поскольку задача В не может освободить счет 1, пока не получит К туп к счету 2, а задача С не может освободить счет 2, пока не получит доступ к счету 1, программа обслуживания счетов электронного банка будет оставаться заблокированной. Обратите внимание на то, что задачи В и С могут ввести в состояние бесконечной отсрочки и другие задачи (если таковые имеются в системе). Если другие задачи ожидают получения доступа к счетам 1 или 2, а задачи В и С «скованы» взаимоблокировкой, то те другие задачи будут ожидать условия, которое никогда не выполнится. При координации параллельно выполняемых задач необходимо помнить, что взаимоблокировка и бесконечная отсрочка — это самые опасные преграды, которые нужно предусмотреть и избежать.

Рис. 2.3. Ситуация взаимоблокировки между задачами В и С

Проблема №4: трудности организации связи

Многие распространенные параллельные среды (например, кластеры) зачастую состоят из гетерогенных компьютерных сетей. Гетерогенные компьютерные сети— это системы, которые состоят из компьютеров различных типов, работающих в общем случае под управлением различных операционных систем и использующих различные сетевые протоколы. Их процессоры могут иметь различную архитектуру, обрабатывать слова различной длины и использовать различные машинные языки. Помимо разных операционных систем, компьютеры могут различаться используемыми стратегиями планирования и системами приоритетов. Хуже того, все системы могут различаться параметрами передачи данных. Это делает обработку ошибок и исключительных ситуаций (исключений) особенно трудной. Неоднородность системы может усугубляться и другими различиями. Например, может возникнуть необходимость организации совместного использования данных программами, написанными на различных языках или разработанных с использованием различных моделей ПО. Ведь общее системное решение может быть реализовано по частям, написанным на языках Fortran, С++ и J ava . Это вносит проблемы межъязыковой связи. И даже если распределенная или параллельная среда не является гетерогенной, остается проблема взаимодействия между несколькими процессами или потоками. Поскольку каждый процесс имеет собственное адресное пространство, то для совместного использования переменных, параметров и значений, возвращаемых функциями, необходимо применять технологию межпроцессного взаимодействия (interprocess communication — IPC), или МПВ-технологию. И хотя реализация МПВ-методов необязательно является самой трудной частью разработки системы ПО, тем не менее они образуют дополнительный уровень проектирования, тестирования и отладки в создании системы.

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

• файлы со средствами блокировки и разблокировки;

• каналы (неименованные, именованные и FIFO-очереди);

• общая память и сообщения;

• сокеты;

• семафоры.

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

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

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

Таблица2.1. Комбинации параллельного и распределенного программирования с различными конфигурациями аппаратного обеспечения

Один компьютер

Множество компьютеров

Параллельное программирование

Оснащен множеством процессоров. Использует логическое разбиение на несколько потоков или процессов. Потоки или процессы могут выполняться на различных процессорах. Для координации задач требуется МПВ-технология

Использует такие библиотеки, как PVM. Требует организации взаимодействия посредством передачи сообщений, что обычно связано с распределенным программированием

Распределенное программирование

Наличие нескольких процессоров не является обязательным. Логика ПО может быть разбита на несколько процессов или потоков. Для координации задач требуется МПВ-технология

Реализуется с помощью сокетов и таких компонентов, как CORBA ORB (Object Request Broker — брокер объектных запросов). Может использовать тип взаимодействия, который обычно связан с параллельным программированием

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

Отказы оборудования и поведение ПО

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

Негативные последствия излишнего параллелизма и распределения

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

Всегда необходимо отличать работу и ресурсы, задействованные в управлении параллельными аппаратными средствами, от работы, направленной на управление параллельно выполняемыми процессами и потоками в ПО. Предел числа программных процессов может быть достигнут задолго до того, как будет достигнуто оптимальное количество процессоров или компьютеров. И точно так же можно наблюдать снижение эффективности оборудования еще до достижения оптимального количества параллельно выполняемых задач.

Выбор архитектуры

Существует множество архитектурных решений, которые поддерживают параллелизм. Архитектурное решение можно считать корректным, если оно соответствует декомпозиции работ (work breakdown structure — WBR) программного обеспечения (ДР ПО). Параллельные и распределенные архитектуры могут быть самыми разнообразными. В то время как некоторые распределенные архитектуры прекрасно работают в Web-среде, они практически обречены на неудачу в среде с реальным масштабом времени. Например, распределенные архитектуры, которые рассчитаны на длинные временные задержки, вполне приемлемы для Web-среды и совершенно неприемлемы для многих сред реального времени. Достаточно сравнить распределенную обработку данных в Web-ориентированной системе функционирования электронной почты с распределенной обработкой данных в банкоматах, или автоматических кассовых машинах (automated teller machine— ATM). Задержка (время ожидания), которая присутствует во многих почтовых Web-системах, была бы попросту губительной для таких систем реального времени, как банкоматы. Одни распределенные архитектуры (имеются в виду некоторые асинхронные модели) справляются с временными задержками лучше, чем другие. Кроме того, необходимо самым серьезным образом подходить к выбору соответствующих архитектур параллельной обработки данных. Например, методы векторной обработки данных наилучшим образом подходят для решения определенных математических задач и проблем имитационного моделирования, но они совершенно неэффективны в применении к мультиагентным алгоритмам планирования. Распространенные архитектуры ПО, которые поддерживают параллельное и распределенное программирование, показаны в табл. 2.2.

Четыре базовые модели, перечисленные в табл. 2.2, и их вариации обеспечивают основу для всех параллельных типов архитектур (т.е. объектно-ориентированного, агентно-ориентированного и «классной доски»), которые рассматриваются в этой книге. Разработчикам ПО необходимо подробно ознакомиться с каждой из этих моделей и их приложением к параллельному и распределенному программированию. Мы считаем своим долгом предоставить читателю введение в эти модели и дать библиографические сведения по материалам, которые позволят найти о них более детальную информацию. В каждой работе или при решении проблемы лучше всего искать естественный или присущий им параллелизм, а выбранный тип архитектуры Должен максимально соответствовать этому естественному параллелизму . Например, параллелизм в решении, возможно, лучше описывать с помощью симметричной модели, или модели сети с равноправными узлами (peer-to-peer model), в которой все сотрудники (исполнители) считаются равноправными, в отличие от несимметричной Модели «управляющий/рабочий», в которой существует главный (ведущий) процесс, Управляющий всеми остальными процессами как подчиненными.

Модель

Архитектура

Распределенное программирование

Параллельное программирование

Модель ведущего узла, именуемая также:

Главный узел управляет задачами, т.е. контролирует их выполнение и передает работу подчиненным задачам

Ѵ

Ѵ

• главный/подчиненный;

• управляющий/рабочий;

• клиент/сервер

Модель равноправных узлов

Все задачи, в основном, имеют одинаковый ранг, и работа между ними распределяется равномерно

Ѵ

Векторная или конвейерная (поточная)обработка

Один исполнительный узел соответствует каждому элементу массива (вектора) или шагу конвейера

Ѵ

Ѵ

Дерево с родительскими и дочерними элементами

Динамически генерируемые исполнители в отношении типа «родитель/потомок». Этот тип архитектуры полезно использовать в алгоритмах следующих типов:

Ѵ

Ѵ

• рекурсия;

• «разделяй и властвуй»; •И/ИЛИ

• древовидная обработка

Различные методы тестирования и отладки

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

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

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

При создании документации на проектирование параллельного или распределенного ПО необходимо описать декомпозицию работ и их синхронизацию, а также взаимодействие между задачами, объектами, процессами и потоками. При этом проектировщики должны тесно контактировать с разработчиками, а разработчики — с теми, кто будет поддерживать систему и заниматься ее администрированием. В идеале это взаимодействие должно осуществляться по действующим стандартам. Однако найти единый язык, понятный всем сторонам и позволяющий четко представить мультипарадигматическую природу всех этих систем, — трудно достижимая цель. Мы остановили свой выбор на языке UML (Unified Modeling Language — унифицированный язык моделирования). В табл. 2.3 перечислено семь UML-диаграмм, которые часто используются при создании многопоточных, параллельных или распределенных программ.

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

Таблица 2.3. UML-диаграммы, используемые при создании многопоточных, параллельных или распределенных программ

Диаграмма (видов) деятельности - разновидность диаграммы состояний, в которой большинство состояний (или все) представляют виды деятельности, а большинство переходов (или все) активизируются при выполнении некоторого действия в исходных состояниях

Диаграмма взаимодействия - Тип диаграммы, которая отображает взаимодействие между объектами. Взаимодействия описываются в виде сообщений, которыми они обмениваются. К диаграммам взаимодействия относятся диаграммы сотрудничества, диаграммы последовательностей и диаграммы (видов)деятельности

Диаграмма (параллельных) состояний - Диаграмма, которая показывает последовательность преобразований объекта в процессе его реакции на события. При использовании диаграммы параллельных состояний эти преобразования могут происходить в течение одного и того же интервала времени

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

Диаграмма сотрудничества - Диаграмма взаимодействия, в которой отображается организация структуры объектов, принимающих или отправляющих сообщения (с акцентом на структурной организации)

Диаграмма развертывания (внедрения) - Диаграмма, которая показывает динамическую конфигурацию узлов обработки, аппаратных средств и программных компонентов в системе

Диаграмма компонентов - Диаграмма взаимодействия, в которой отображается организация физических модулей программного кода (пакетов) в системе и зависимости между ними

Резюме

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

Разбиение С++ программ на множество задач

Коль выполнение параллельных процессов возможно на более низком (нейронном) уровне, то на символическом уровне мышление человека с принципиальной точки зрения можно рассматривать как последовательную машину, которая использует временно создаваемые последовательности процессов, выполнение которых длится сотни миллисекунд.

Герберт Саймон(Негbеrt. Simon), The Machine As Mind

—

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

Определение процесса

Процесс (process) — это некоторая часть (единица) работы, создаваемая операционной системой. Важно отметить, что процессы и программы — необязательно эквивалентные понятия. Программа может состоять из нескольких процессов. В некоторых ситуациях процесс может быть не связан с конкретной программой. Процессы - это артефакты операционной системы, а программы — это артефакты разработчика. Такие операционные системы, как UNIX/Linux позволяют управлять сотнями или даже тысячами параллельно загружаемых процессов.

Чтобы некоторую часть работы можно было назвать процессом, она должна иметь адресное пространство, назначаемое операционной системой, и идентификатор, или идентификационный номер (id процесса). Процесс должен обладать определенным статусом и иметь свой элемент в таблице процессов. В соответствии со стандартом POSIX он должен содержать один или несколько потоков управления, выполняющихся в рамках его Процесс состоит из множества выполняющихся инструкций, размещенных в адресном пространстве этого процесса. Адресное пространство процесса распределяется между инструкциями, данными, принадлежащими процессу, и стеками, обеспечивающими вызовы функций и хранение локальных переменных.

Два вида процессов

При выполнении процесса операционная система назначает ему некоторый процессор. Процесс выполняет свои инструкции в течение некоторого периода времени. Затем он выгружается, освобождая процессор для другого процесса. Планировщик операционной системы переключается с кода одного процесса на код другого, предоставляя каждому процессу шанс выполнить свои инструкции. Различают пользовательские процессы и системные. Процессы, которые выполняют системный код, называются системными и применяются к системе в целом. Они занимаются выполнением таких служебных задач, как распределение памяти, обмен страницами между внутренним и вспомогательным запоминающими устройствами, контроль устройств и т.п. Они также выполняют некоторые задачи «по поручению» пользовательских процессов, например, делают запросы на ввод-вывод данных, выделяют память и т.д. Пользовательские процессы выполняют собственный код и иногда обращаются к системным функциям. Выполняя собственный код, пользовательский процесс пребывает в пользовательском режиме (user mode). В пользовательском режиме процесс не может выполнять определенные привилегированные машинные команды. При вызове системных функций (например read(), write () или open ()) пользовательский процесс выполняет инструкции операционной системы. При этом пользовательский процесс «удерживает» процессор до тех пор, пока не будет выполнен системный вызов. Для выполнения системного вызова процессор обращается к ядру операционной системы. В это время о пользовательском процессе говорят, что он пребывает в привилегированном режиме, или режиме ядра (kernel mode), и не может быть выгружен никаким другим пользовательским процессом.

Блок управления процессами

Процессы имеют характеристики, используемые для идентификации и определения их поведения. Ядро поддерживает необходимые структуры данных и предоставляет системные функции, которые дают возможность пользователю получить доступ к этой информации. Некоторые данные хранятся в блоках управления процессами (process control block—PCB), или БУП. Данные, хранимые в БУП-блоках, описывают процесс с точки зрения потребностей операционной системы. С помощью этой информации операционная система может управлять каждым процессом. Когда операционная система переключается с одного процесса на другой, она сохраняет текущее состояние выполняющегося процесса и его контекст в области сохранения БУП-блока, чт обы надлежащим образом возобновить выполнение этого процесса в следующий раз, когда ему снова будет выделен центральный процессор (ЦП). БУП-блок считывается и обновляется различными модулями операционной системы. Модули «отвечают» за контроль производительности операционной системы, планирование, распределение ресурсов и доступ к механизму обработки прерываний и/или модифицируют БУП-блок. Блок БУП содержит следующую информацию:

• текущее состояние и приоритет процесса;

• идентификатор процесса, а также идентификаторы родительского и сыновнего процессов;

• указатели на выделенные ресурсы;

• указатели на область памяти процесса;

• указатели на родительский и сыновний процесс;

• процессор, занятый процессом;

• регистры управления и состояния;

• стековые указатели.

Среди данных, содержащихся в БУП-блоке, есть такие, которые «отвечают» за управление процессом, т.е. отражают его текущее состояние и приоритет, указывают на БУП-блоки родительского и сыновнего процессов, а также выделенные ресурсы и память. Кроме того, этот блок включает информацию, связанную с планированием, привилегиями процессов, флагами, сообщениями и сигналами, которыми обмениваются процессы (имеется в виду межпроцессное взаимодействие— mterprocess communication, или IPC). С помощью информации, связанной с управлением процессами, операционная система может координировать параллельно выполняемые процессы. Стековые указатели и содержимое регистров пользователя, управления и состояния содержат информацию, связанную с состоянием процессора. При выполнении процесса соответствующая информация размещается в регистрах ЦП. При переключении операционной системы с одного процесса на другой вся информация из этих регистров сохраняется. Когда процесс снова получает ЦП во «временное пользование», ранее сохраненная информация может быть восстановлена. Есть еще один вид информации, который связан с идентификацией процесса. Имеется в виду идентификатор процесса (id), или PID, и идентификатор родительского процесса (PPID). Эти идентификационные номера (которые представлены положительными целочисленными значениями) уникальны для каждого процесса.

Анатомия процесса

Адресное пространство процесса делится на три логических раздела: текстовый (для кода программы), информационный (для данных программы) и стековый (для стеков программы). Логическая структура процесса показана на рис.3.1. Текстовый раздел (расположенный в нижней части адресного пространства) содержит подлежащие выполнению инструкции, которые называются программным кодом. Раздел данных (расположенный над текстовым разделом) содержит инициализированные глобальные, внешние и статические переменные процесса. Раздел стеков содержит локально создаваемые переменные и параметры, передаваемые функциям. Поскольку процесс может вызывать как системные функции, так и функции, определенные пользователем, в стековом разделе поддерживаются два стека: стек пользователя и стек ядра. При вызове функции создается стековый фрейм функции, который помещается в стек пользователя или стек ядра в зависимости от того , в каком режиме пребывает процесс в данный момент: в пользовательском или привилегированном (режиме ядра). Стековый раздел имеет тенденцию расти в направлении раздела данных. При выходе из функции ее стековый фрейм извлекается из стека. Разделы кода, данных и стеков, а также блок управления процессом образуют часть того, из чего складывается образ процесса (process image).

Рис. 3.1. Адресное пространство процесса делится на три логических раздела: текстовый, информационный и стековый. Так выглядит логическая структура процесса

Адресное пространство процесса виртуально. Применение виртуальной памяти позволяет отделить адреса, используемые в текущем процессе, от адресов, реально доступных во внутренней памяти. Тем самым значительно увеличивается задействованное пространство адресов памяти по сравнению с реально доступными адресами. Разделы виртуального адресного пространства процесса представляют собой смежные блоки памяти. Каждый такой раздел и физическое адресное пространство разделены на участки памяти, именуемые страницами. У каждой страницы есть уникальный номер страничного блока (page frame number). В качестве индекса для входа в таблицы страничных блоков (page frame table) используется номер виртуального страничного блока. Каждый элемент таблицы страничных блоков содержит номер физического страничного блока, что позволяет установить соответствие между виртуальными и физическими страничными блоками. Это соответствие отображено на рис. 3.2. Как видите, виртуальное адресное пространство непрерывно, но устанавливаемое с его помощью соответствие физическим страницам не является упорядоченным. Другими словами, при последовательных виртуальных адресах соответствующие им физические страницы не будут последовательными.

Несмотря на то что виртуальное адресное пространство каждого процесса защищено, т.е. приняты меры по предотвращению доступа к нему со стороны другого процесса, текстовый раздел [6] процесса может совместно использоваться несколькими процессами. На рис. 3.2 также показано, как два процесса могут разделять один и тот же программный код. При этом в элементах таблиц страничных блоков обоих процессов хранится один и тот же номер физического страничного блока. Как показано на рис. 3.2, виртуальный страничный блок с номером 0 процесса А соответствует физическому страничному блоку с номером 5, что также справедливо и для виртуального страничного блока с номером 2 процесса В.

Рис. 3.2. Соответствие последовательных виртуальных страничных блоков страницам физической памяти (НСБ — номер страничного блока; НВСБ— номер виртуального страничного блока)

Чтобы операционная система могла управлять всеми процессами, хранимыми во внутренней памяти, она создает и поддерживает таблицы процессов (process table). В действительности операционная система содержит отдельные таблицы для всех объектов, которыми она управляет. Следует иметь в виду, что операционная система управляет не только процессами, но и всеми ресурсами компьютера, т.е. устройствами ввода-вывода, памятью и файлами. Часть памяти, устройств и файлов управляется от имени пользовательских процессов. Эта информация отмечена в БУП-блоках как ресурсы, выделенные процессу. Таблица процессов должна иметь соответствующую структуру для каждого образа процесса в памяти. Каждая такая структура содержит идентификаторы (id) самого процесса и родительского процесса, идентификаторы реального и эффективного пользователей, идентификатор группы, список подвешенных сигналов, местоположение текстового, информационного и стекового разделов, а также текущее состояние процесса. Если операционной системе нужен доступ к определенному процессу, в таблице процессов разыскивается информация о нем, а затем в памяти размещается его образ (рис. 3.3).

Рис. 3.3. Операционная система управляет таблицами. Каждая структура в массиве таблиц процессов представляет процесс в системе

Состояния процессов

Во время выполнения процесса его состояние изменяется. Под состоянием процесса подразумевается его текущий режим, или статус. В среде UNIX процесс может пребывать в одном из следующих состояний:

• выполнения;

• работоспособности (готовности);

• «зомби»;

• ожидания (блокирования);

• останова.

Состояние процесса меняется при определенных обстоятельствах, создаваемых существованием процесса или операционной системы. Под сменой состояний, или переходом из одного состояния в другое, понимают обстоятельства, которые заставляют процесс изменить свое состояние. На рис. 3.4 отображена диаграмма состояний для среды UNIX. Диаграмма состояний содержит узлы и направленные ребра, соединяющие эти узлы. Каждый узел представляет состояние процесса, а направленные ребра между узлами — переходы из одного состояния в другое. Возможные смены состояний (с их кратким описанием) перечислены в табл. 3.1. На рис. 3.4 и в табл. 3.1 показано, что между состояниями разрешены только определенные переходы. Например, между состояниями готовности и выполнения существует переход (ребро диаграммы), а между состояниями ожидания и выполнения — нет. Это означает, что возможны обстоятельства, заставляющие процесс перейти из состояния готовности в состояние выполнения, но нет обстоятельств, которые могут заставить процесс перейти в состояние выполнения из состояния ожидания.

Рис. 3.4. Состояния процессов и переходы между ними в средах UNIX/Linux

Когда процесс только создается, он готов к выполнению своих инструкций, но должен ожидать «своего часа» до тех пор, пока не освободится процессор. Каждому процессу единолично разрешается использовать процессор в течение дискретного временного интервала, именуемого квантом времени (time slice). Процессы, ожидающие использования процессора, «занимают» очередь, т.е. помещаются в очереди готовых процессов. Только из таких очередей планировщик выбирает процесс, который будет использовать процессорное время. Процессы, находящиеся в очередях готовых процессов, пребывают в состоянии работоспособности. Когда процессор становится доступным,

Таблица 3 .1 Переходы процессов из одного состояние в другое

Готовый → выполняющийся (загрузка) Процесс назначается процессору

Выполняющийся →готовый (конец кванта времени) Квант времени процесса, который назначен процессору, истек. Процесс возвращается назад в очередь готовых процессов

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

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

Ожидающий → готовый (разблокировка) Событие, наступления которого ожидал процесс, произошло, или завершилось выполнение системной функции, например, удовлетворен запрос на ввод-вывод данных

Выполняющийся → остановленный Процесс отказывается от процессора из-за получения им сигнала останова

Остановленный → готовый Процесс получил сигнал продолжать и возвращается назад в очередь готовых процессов

Выполняющийся → «Зомби» Процесс прекращен и ожидает, пока родительский процесс не извлечет из таблицы процессов его статус завершения

«Зомби» → ВЫХОД Родительский процесс извлекает из таблицы процессов статус завершения и процесс-зомби покидает систему

Выполняющийся → ВЫХОД Процесс завершен, но он покидает систему после того как родительский процесс извлечет из таблицы процессов его статус завершения

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

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

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

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

Планирование процессов

Если готовых к выполнению процессов больше одного, планировщик должен определить, какой из них первым назначить процессору. С этой целью планировщик поддерживает структуры данных, которые позволяют наиболее эффективным образом распределять между процессами процессорное время. Каждый процесс получает класс (тип) приоритета и размещается в соответствующей очереди вместе с другими работоспособными процессами того же приоритетного класса. Поэтому существует несколько приоритетных очередей, которые представляют различные классы приоритетов, используемые системой. Эти приоритетные очереди упорядочиваются и помещаются в массив распределения, именуемый также многоуровневой приоритетной очередью (multilevel priority queue), показанной на рис. 3.5 . Каждый элемент этого массива связан с конкретной приоритетной очередью. Для выполнения процессором планировщик назначает тот процесс, который стоит в головной части непустой очереди, имеющей самый высокий приоритет.

Приоритеты могут быть динамическими или статическими. Однажды установленный статический приоритет процесса изменить нельзя, а динамические — можно. Процессы с самым высоким приоритетом могут монополизировать использование процессора. Если же приоритет процессора динамический, то его начальный уровень может быть заменен более высоким значением, в результате чего такой процесс будет переведен в очередь с более высоким приоритетом. Кроме того, процесс, который монополизирует процессор, может получить более низкий приоритет, или же другие процессы могут получить более высокий приоритет, чем процесс-монополист. В средах UNIX/Linux для уровней приоритетов предусмотрен диапазон от -20 до 19. Чем выше значение уровня, тем ниже приоритет процесса.

При назначении приоритета пользовательскому процессу следует учитывать, на что именно этот процесс тратит большую часть времени. Одни процессы отличаются повышенной интенсивностью использования процессорного времени (они используют процессор в течение всего кванта процессорного времени). У других же большая часть времени уходит на ожидание выполнения операций ввода-вывода или наступления некоторых иных событий. Если такой процесс готов к использованию процессора, ему следует немедленно предоставить процессор, чтобы он мог сделать следующий запрос к устройствам ввода-вывода. Процессы, которые взаимодействуют между собой, могут требовать довольно высокий приоритет, чтобы рассчитывать на приличное время реакции. Системные процессы имеют более высокий приоритет, чем пользовательские.

Рис. 3.5. Многоуровневая приоритетная очередь (массив распределения), каждый элемент которой указывает на очередь готовых процессов с одинаковым уровнем приоритета

Стратегия планирования

Процессы размещаются в приоритетных очередях в соответствии со стратегией Планирования. В системах UNIX/Linux используются две стратегии планирования: FIFO (сокр. от First In First Out, т.е. первым прибыл, первым обслужен) и RR (сокр. От round-robin, т.е. циклическая). Схема действия стратегии FIFO показана на рис. 3.6, а. При использовании стратегии FIFO процессы назначаются процессору в соответствии со временем поступления в очередь. После истечения кванта времени процесс помещается в начало (головную часть) своей приоритетной очереди. Когда ждущий процесс становится работоспособным (готовым к выполнению), он помещается в конец своей приоритетной очереди. Процесс может вызвать системную функцию и отказаться от процессора в пользу другого процесса с таким же уровнем приоритета. Такой процесс также будет помещен в конец своей приоритетной очереди.

Рис.3.6. Схемы действия FIFO- и RR-стратегий планирования При использовании стратегии FIFO процессы назначаются процессору в соответствии со временем поступления в очередь. При использовании стратегии RR процессы назначаются процессору по правилам FIFO-стратегии, но с одним отличием: после истечения кванта времени процесс помещается не в начало, а в конец своей приоритетной очереди

В соответствии с циклической стратегией планирования (RR) все процессы счи таются равноправными (см. рис. 3.6, б) . RR-планирование совпадает с FIFO-планированием с одним исключением: после истечения кванта времени процесс помещает ся не в начало, а в конец своей приоритетной очереди, и процессору назначается след ующий (по очереди) процесс.

Использование утилиты ps

Утилита ps генерирует отчет, который содержит статистические данные о выполнении текущих процессов. Эту информацию можно использовать для контроля за их состоянием. В табл. 3.8 перечислены общие заголовки и описаны выходные данные, генерируемые утилитой ps для сред Solaris/Linux. В любой многопроцессорной среде утилита ps успешно применяется для мониторинга состояния процессов, степени использования ЦП и памяти, приоритетов и времени запуска текущих процессов. Ниже приведены командные опции, которые позволяют управлять информацией, содержащейся в отчете (с их помощью можно уточнить, что именно и какие процессы вас интересуют). В среде Solaris по умолчанию (без командных опций) отображается информация о процессах с тем же идентификатором эффективного пользователя и управляющим терминалом инициатора вызова. В среде Linux по умолчанию отображается информация о процессах, id пользователя которых совпадает с id инициатора запуска. В обеих средах в этом случае отображаемая информация, ограниченная следующими составляющими: PID, TTY, TIME и COMMAND. Перечислим опции, которые позволяют получить информацию о нужных процессах.

-t term Список процессов, связанных с терминалом, заданным значением term

-e Все текущие процессы

-a (Linux) Все процессы с терминалом tty за исключением лидеров сеанса

(Solaris) Большинство часто запрашиваемых процессов за исключением лидеров группы и процессов, не связанных с терминалом

-d Все текущие процессы за исключением лидеров сеанса

T (Linux) Все процессы, связанные с данным терминалом

a (Linux) Все процессы, включая процессы остальных пользователей

r (Linux) Только выполняющиеся процессы

Таблица 3 .2. Общие заголовки, используемые для утилиты ps в средах Solaris/Linux

USER, UID Пользовательское имя владельца процесса

PID ID процесса

PPID ID родительского процесса

PGID ID лидирующего процесса в группе

SlD ID лидера сеанса

%CPU Коэффициент использования времени ЦП (в процентах) процессом

в течение последней минуты

RSS   Объем реального ОЗУ, занимаемый процессом в данный момент (в Кбайт)

%MEM   Коэффициент использования реального ОЗУ процессом в течение последней минуты

SZ Размер виртуальной памяти, занимаемой данными и стеком процесса (в Кбайт или страницах)

WCHAN Адрес события, в ожидании которого процесс пребывает в состоянии ожидания

COMMAND Имя команды и аргументы

CMD

TT, TTY   Управляющий терминал процесса

S, STAT   Текущее состояние процесса

TIME Общее время ЦП, используемое процессом (HH:MM:SS)

STIME, START Время или дата старта процесса

NI   Фактор уступчивости процесса

PRI   Приоритет процесса

С, CP   Коэффициент краткосрочного использования ЦП для вычисления планировщиком значения PRI

ADDR Адрес памяти, выделенной процессу

LWP   ID потока

NLWP Количество потоков

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

– f полные распечатки

– -l в длинном формате

– - j в формате задания

Приведем пример использования утилиты ps в средах Solaris/Linux:

ps -f

По этой команде будет отображена полная информация о процессах, которая выводится по умолчанию в каждой среде. На рис. 3.7 показан результат выполнения этой команды в среде Solaris. Командные опции можно использовать тандемом (одна за другой). На рис 3 7 также показан результат совместного использования опций -l и -f в среде Solaris:

ps -lf

Командная опция l позволяет отобразить дополнительные заголовки: F, S, С, PRI, NI , ADDR и WCHAN. При использовании командной опции P отображается заголовок PSR, означающий номер процессора, которому назначается (или за которым закрепляется) процесс.

$ ps -f

UID PID PPID C STIME TTY TIME CMD

cameron 2214 2212 0 21:03:35 pts/12 0:00 -ksh

cameron 2396 2214 2 11:55:49 pts/12 0:01 nedit

$ ps -lf

F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD

8 S cameron 2214 2212 0 51 20 70e80f00 230 70e80f6c 21:03:35 pts/12 0:00 -ksh

8 S cameron 2396 2214 1 53 24 70d747b8 843 70152aba 11:55:49 pts/12 0:01 nedit

Рис. 3.7. Результат выполнения команд ps -f и ps -lf в среде Solaris

На рис. 3.8 показан результат выполнения утилиты ps с использованием командных опций Tux в среде Linux. Данные, выводимые с помощью заголовков %CPU, %MEM и STAT, отображаются для процессов. В многопроцессорной среде с помощью этой информации можно узнать, какие процессы являются доминирующими с точки зрения использования времени ЦП и памяти. Заголовок STAT отображает состояние или статус процесса. Ниже приведены символы, обозначающие статус, и дано соответствующее описание. Заголовок STAT позволяет узнать дополнительную информацию о статусе процесса.

D (BSD) Ожидание доступа к диску

P (BSD) Ожидание доступа к странице

X (System V) Ожидание доступа к памяти

W (BSD) Процесс выгружен на диск

К (AIX) Доступный процесс ядра

N (BSD) Приоритет выполнения понижен

> (BSD) Приоритет выполнения повышен искусственно

< (Linux) Процесс с высоким приоритетом

L (Linux) Страницы заблокированы в памяти

Эти символы должны предшествовать коду статуса. Например, если перед кодом статуса стоит символ N, значит, процесс выполняется с более низким уровнем приоритета. Если код статуса процесса отображен символами SW<, это означает, что процесс пребывает в ждущем режиме, выгружен и имеет высокий уровень приоритета.

Установка и получение приоритета процесса

Уровень приоритета процесса можно изменить с помощью функции nice (). Каждый процесс имеет фактор уступчивости (nice value), который используется для вычисления уровня приоритета вызывающего процесса. Процесс наследует приоритет процесса, который его создал. Чтобы понизить приоритет процесса, следует увеличить его фактор уступчивости. Лишь процессы привилегированных пользователей и ядра системы могут увеличивать уровни своих приоритетов.

Синопсис

#include <unistd.h> int nice(int incr);

Чем ниже фактор уступчивости, тем выше уровень приоритета процесса. Параметр incr содержит значение, добавляемое к текущему фактору уступчивости вызывающего процесса. Значение параметра incr может быть отрицательным или положительным, а фактор уступчивости представляет собой неотрицательное число. Положительное значение incr увеличивает фактор уступчивости, а значит, понижает уровень приоритета. Отрицательное значение incr уменьшает фактор уступчивости, тем самым повышая уровень приоритета. Если значение incr изменяет фактор уступчивости выше или ниже соответствующих предельных величин, он будет установлен равным самому высокому или самому низкому пределу соответственно. При успешном выполнении функция nice () возвращает новый фактор уступчивости процесса, в противном случае — число -1, а прежнее значение фактора уступчивости при этом не изменяется.

Синопсис

#include <sys/resource.h>

int getpriority(int which, id_t who);

int setpriority(int which,   id_t who, int value); _

Функция setpriority() устанавливает фактор уступчивости для заданного процесса, группы процессов или пользователя. Функция getpriority() возвращает приоритет заданного процесса, группы процессов или пользователя. Синтаксис использования функций setpriority() и getpriority() для установки и считывания фактора уступчивости текущего процесса демонстрируется в листинге 3.1.

Листинг 3.1. Использование функций setpriority() и  getpriority()

#include <sys/resource.h>

//...

id_t pid = 0;

int which = PRIO_PROCESS;

int value = 10;

int nice_value;

int ret;

nice_value = getpriority(which,pid);

if(nice_value < value){

ret = setpriority(which,pid,value);

}

//.-•

В листинге 3.1 возвращается и устанавливается приоритет вызывающего процесса. Если фактор уступчивости вызывающего процесса оказывается меньше 10, он устанавливается равным 10. Процесс задается значениями, хранимыми в параметрах which и who (см. соответствующий синопсис). Параметр which может определять процесс, группу процессов или пользователя и иметь следующие значения.

PRIO_PROCESS Означает процесс

PRIO_PGRP Означает группу процессов

PRIO_USER Означает пользователя

В зависимости от значения параметра which параметр who содержит идентификационный номер (id) процесса, группы процессов или эффективного пользователя. В листинге З.1 параметру which присваивается значение PRIO_PROCESS. В листинге З.1 параметр who устанавливается равным 0, означая тем самым текущий процесс. Параметр value для функции setpriority() определяет новое значение фактора уступчивости для заданного процесса, группы процессов или пользователя. Факторы уступчивости в среде Linux должны находиться в диапазоне от -20 до 19 . В листингe 3.1 фактор уступчивости устанавливается равным 10, если текущее его значение оказывается меньше 10 . В отличие от функции nice(), значение, передаваемое функции setpriority(), является фактическим значением фактора уступчивости, а не смещением, которое суммируется с текущим фактором уступчивости.

Если процесс имеет несколько потоков, модификация приоритета процесса повлияет на приоритет всех его потоков. При успешном выполнении функции getpriority() возвращается фактор уступчивости заданного процесса, а при успешном выполнении функции setpriority () — значение 0. В случае неудачи обе функции возвращают число -1. Однако число -1 является допустимым значением фактора уступчивости для любого процесса. Чтобы уточнить, не было ли ошибок при выполнении функции getpriority(), имеет смысл протестировать внешнюю переменную errno .

Переключение контекста

Переключение контекста происходит в момент, когда процессор переключается с одного процесса на другой. При переключении контекста система сохраняет контекст текущего процесса и восстанавливает контекст следующего процесса, выбранного для использования процессора. БУП-блок прерванного процесса при этом обновляется, а также изменяется значение поля состояния процесса (т.е. признак состояния выполнения заменяется признаком другого состояния: готовности, блокирования или «зомби»). Сохраняется и обновляется содержимое регистров процессора, состояние стека, данные об идентификации (и привилегиях) пользователя и процесса, а также о стратегии планирования и учетная информация.

Система должна отслеживать статус устройств ввода-вывода процесса и других ресурсов, а также состояние всех структур данных, связанных с управлением памятью. Вы г руженный (прерванный) процесс помещается в соответствующую очередь.

Переключение контекста происходит в случаях, когда:

• процесс выгружается;

• процесс добровольно отказывается от процессора;

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

• процесс переходит из пользовательского режима в режим ядра.

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

Создание процесса

Чтобы выполнить любую программу, операционная система должна сначала создать процесс. При создании нового процесса в главной таблице процессов создается новая структура. Создается и инициализируется новый блок БУП, и в его раздел идентификации процесса записывается уникальный идентификационный номер процесса (id) и id родительского процесса. Программный счетчик устанавливается указателем на входную точку программы, а указатели системных стеков устанавливаются таким образом, чтобы определить стековые границы для процесса. Процесс инициализируется любыми требуемыми атрибутами. Если процессу не присвоено значение приоритета, то по умолчанию ему присваивается самое низкое значение. Изначально процесс не обладает никакими ресурсами, если нет явного запроса на ресурсы или если они не были унаследованы от процесса-создателя. Процесс «входит» в состояние выполнения и помещается в очередь готовых к выполнению процессов. Для него выделяется адресное пространство, размер которого определяется по умолчанию на основе типа процесса. Кроме того, размер можно установить по запросу от создателя процесса. Процесс-создатель может передать системе размер адресного пространства в момент создания процесса.

Отношения между родительскими и сыновними процессами

Процесс, который создает, или порождает, другой процесс, является родительским (parent) процессом по отношению к порожденному, или сыновнему (child) процессу. Процесс init — родитель (или предок) всех пользовательских процессов — первый процесс, видимый системой UNIX после ее загрузки. Процесс init организует систему, при необходимости выполняет другие программы и запускает демон-программы (daemon), т.е. сетевые программы, работающие в фоновом режиме. Идентификатор процесса init (PID) равен 1. Сыновний процесс имеет собственный уникальный идентификатор PID, БУП-блок и отдельную структуру в таблице процессов. Сыновний процесс также может породить новый процесс. Выполняющееся приложение может создать дерево процессов. Например, родительский процесс выполняет поиск накопителя на жестких дисках для заданного HTML-документа. Имя этого HTML-документа записано в глобальной структуре данных, подобной списку, который содержит все запросы на документы. После успешного обнаружения документ удаляется из списка запросов, и его путь (маршрут в сети) записывается в другую глобальную структуру данных, которая содержит пути найденных документов. Чтобы обеспечить

Приемлемую реакцию на пользовательские запросы, для процесса предусматривается ограничение в виде пяти необработанных запросов в списке. По достижении этого Предела порождаются два новых процесса. Если порожденный процесс в свою очередь достигнет установленного предела, он создаст еще два новых процесса. Создаваемое таким способом дерево процессов показано на рис. 3.9. Любой процесс может иметь только один родительский, но множество сыновних процессов.

Рис. 3.9. Дерево процессов. При определенных условиях процесс порождает два новых потомка

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

Некоторые атрибуты родителя не наследуются потомком. Как упоминалось выше, сыновний процесс не наследует PID родителя и его БУП-блок. Потомок не наследует никаких файловых блокировок, созданных родителем или необработанными сигна лами . Д ля сыновнего процесса используются собственные значения таких временных характеристик, как коэффициент загрузки процессора и время создания. Несмотря на то, что сыновние процессы связаны определенными отношениями с родителями, они все же функционируют как отдельные процессы. Их программные и стековые счетчики действуют раздельно. Поскольку разделы данных копируются, а не используются совместно, процесс-потомок может изменять значения своих переменных, не оказывая влияния на родительскую копию данных. Родительский и сыновний процесс совместно используют раздел программного кода и выполняют инструкции, расположенные непосредственно после вызова системной функции, создавшей сыновний процесс. Они не выполняют эти инструкции на этапе блокировки из-за соперничества за процессор со всеми остальными процессами, загруженными в память.

После создания образ сыновнего процесса может быть заменен другим исполняемым образом. Разделы программного кода, данных и стеков, а также его «куча» памяти перезаписывается новым образом процесса. Новый процесс сохраняет свои идентификационные номера (PID и PPID). Атрибуты, сохраняемые новым процессом после замены его исполняемого образа, перечислены в табл. 3.3. В ней также указаны системные функции, которые возвращают эти атрибуты. Переменные среды также сохраняются, если во время замены исполняемого образа процесса не были заданы новые переменные среды. Файлы, которые были открыты до момента замены исполняемого образа, остаются открытыми. Новый процесс будет создавать файлы с теми же файловыми разрешениями. Время ЦП при этом не сбрасывается.

Таблица 3.3. Атрибуты, сохраняемые новым процессом после замены его исполняемого образа образом нового процесса

Сохраняемые атрибуты   Функция

Идентификатор (ID) процесса

getpid()

ID родительского процесса

getppid()

ID группы процессов

getpgid()

Сеансовое членство

getsid()

Идентификатор эффективного пользователя

getuid()

Идентификатор эффективной группы

getgid()

Дополнительные ID групп

getgroups()

Время, оставшееся до сигнала тревоги

alarm()

Фактор уступчивости

nice()

Время, используемое до настоящего момента

times ()

Маска сигналов процесса

sigprocmask()

Ожидающие сигналы

sigpending()

Предельный размер файла

ulimit()

Предельный объем ресурсов

getrlimit()

Маска создания файлового режима

umask()

Текущий рабочий каталог

getcwd()

Корневой каталог

Утилита pstree

Утилита pstree в среде Linux отображает дерево процессов (точнее, она отображает выполняющиеся процессы в форме древовидной структуры). Корнем этого дерева является процесс init.

pstree [-a] [-c] [-h | -Hpid] [-l] [-n] [-p] [-u] [-G] | -U] [pid | user]

pstree -V

При вызове этой утилиты можно использовать следующие опции,

-а Отобразить аргументы командной строки,

-h Выделить текущий процесс и его предков.

-H Аналогично опции -h, но выделению подлежит заданный процесс.

-n Отсортировать процессы с одинаковым предком по значению PID, а не

по имени,

-p Отобразить значения PID.

На рис. 3.10 показан результат выполнения команды pstree -h в среде Linux.

ka:~ # pstree -h

init-+-applix

|-atd

|-axmain

|-axnet

|-cron

|-gpm

|-inetd

|-9*[kdeinit]

|-kdeinit -+-kdeinit

| |-kdeinit---bash---gimp---script-fu

| '-kdeinit---bash -+-man---sh---sh---less

| '-pstree

|-kdeinit---cat

|-kdm-+-X

| '-kdm---kde---ksmserver

|-kflushd

|-khubd

|-klogd

|-knotify

|-kswapd

|-kupdate

|-login---bash

|-lpd

|-mdrecoveryd

|-5*[mingetty]

|-nscd---nscd---5*[nscd]

|-sshd

|-syslogd

|-usbmgr

'-xconsole

Ри с . 3.10. Результат выполнения команды pstree -h в среде Linux

Использование системной функции fork()

Системная функция (или системный вызов) fork () создает новый процесс, который представляет собой дубликат вызывающего процесса, т.е. его родителя. При успешном выполнении функция fork () возвращает родительскому и сыновнему процессам два различных значения. Сыновнему возвращается число 0, а родительскому - значение PID сыновнего процесса. Родительский и сыновний процессы продолжают выполняться с инструкции, непосредственно следующей за функцией fork (). В случае неудачного выполнения (оно выражается в том, что сыновний процесс не был создан) родительскому процессу возвращается число -1.

Синопсис

#include <unistd.h>

pid_t fork(void); _

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

Использование семейства системных функций exec

Семейство функций exec предназначено для замены образа вызывающего процесса образом нового процесса. При вызове функции fork () создается новый процесс, который является точной копией родительского процесса, а функция exec () заменяет образ «скопированного» процесса образом копии. Образ нового процесса представляет собой обычный выполняемый файл, который немедленно запускается на выполнение. Этот файл можно задать с помощью имени и пути доступа к нему. Функции семейства exec могут передать новому процессу аргументы командной строки, а также установить переменные среды. Если функция выполнилась успешно, она не возвращает никакого значения, поскольку образ процесса, который содержал обращение к функции exec, уже перезаписан. В случае неудачи вызывающему процессу возвращается число -1. Все функции exec () могут иметь неудачный исход при следующих условиях:

•  разрешения не признаны; разрешение на поиск отвергается для каталога выполняемых файлов; разрешение на выполнение отвергается для выполняемого файла;

•  файлы не существуют, выполняемый файл не существует; каталог не существует;

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

пр облемы с символическими ссылками; при анализе пути к исполняемому файлу символические ссылки образуют циклы; символические ссылки делают путь к исполняемому файлу слишком длинным.

Функции семейства exec используются совместно с функцией fork (). Функция fork () создает и инициализирует сыновний процесс «по образу и подобию» родительского. Образ сыновнего процесса затем заменяет образ своего предка посредством вызова функции exec (). Пример использования функций fork() и exec() показан в листинге 3.2.

//Лис тинг 3.2. Использование системных функций fork() и exec()

RtValue = fork();

if(RtValue == 0){

execl("/path/direct»,«direct»,".»);

}

В листинге 3.2 демонстрируется вызов функции fork(). Значение, которое она возвращает, сохраняется в переменной RtValue. Если значение RtValue равно 0, значит, это — сыновний процесс, и в нем вызывается функция execl() с параметрами. Первый параметр содержит путь к выполняемому модулю, второй — инструкцию для выполнения, а третий — аргумент. Второй параметр, direct, представляет собой имя утилиты, которая перечисляет все каталоги и подкаталоги из данного каталога. Всего существует шесть версий функций exec, предназначенных для использования различных соглашений о вызовах.

Функции execl ()

Функции execl (), execle () и execlp () передают аргументы командной строки в виде списка. Количество аргументов командной строки должно быть известно во время компиляции.

• int execl(const char *path,const char *arg0,.../*,(char * )0 */);

Здесь path — путевое имя выполняемой программы. Его можно задать в виде полного составного имени либо относительного составного имени из текущего каталога. Последующие параметры представляют собой список аргументов командной строки, от arg0 до argn. Всего может быть n аргументов. Этот список завершается NULL -указателем.

• int execle(const char *path,const char *arg0,.../*,(char *)0 *, char *const envp[]*/);

Эта функция аналогична функции execl () с одним отличием: она имеет дополнительный параметр, envp[]. Этот параметр указывает на новую среду для нового процесса, т.е. envp[] — это указатель на строковый массив с завершающим нулевым символом. Каждая его строка, также завершающаяся нулевым символом, имеет следующую форму:

name=value

Здесь name — имя переменной среды, а value — сохраняемая строка. Значение параметру envp [] можно присвоить следующим образом:

char *const envp[] = {«PATH=/opt/kde2:/sbin», «HOME=/home»,NULL};

Здесь PATH и НОМЕ — переменные среды.

• int execlp(const char *file,const char *arg0,.../*, (char *)0 */);

Здесь file — имя выполняемой программы. Для определения местоположения выполняемых программ используется переменная среды PATH. Остальные параметры представляют собой список аргументов командной строки (см. описание функции execl() ) .

Вот примеры применения синтаксиса функций execl () с различными аргументами:

char *const args[] = {«direct»,".»,NULL};

char *const envp[] = {«files=50»,NULL};

execl("/path/direct», «direct», ".», NULL) ;

execle("/path/direct»,«direct»,".»,NULL,envp);

execlp(«direct», «direct», " . ",NULL) ;

Здесь в каждом примере вызова execl -функции активизированный процесс выполняет программу direct.

Синопсис

#include <unistd.h>

int execl(const char *path,const char *arg0,.../*,(char *)0 */);

int execle(const char *path,const char *arg0,.../*,(char *)0 *,char *const envp[]*/);

int execlp(const char *file,const char *arg0,.../*,(char *)0 */);

int execv(const char *path,char *const arg[]);

int execve(const char *path,char *const arg[],char *const envp[]); int execvp(const char *file,char *const arg[]);

Функции execv ()

Функции execv(), execve() и execvp() передают аргументы командной строки в векторе указателей на строки с завершающим нулевым символом. Количество аргументов командной строки должно быть известно во время компиляции. Элемент argv[0] обычно представляет собой команду.

• int execv(const char *path,char *const arg[]);

Здесь path — путевое имя выполняемой программы. Его можно задать в виде полного составного имени либо относительного составного имени из текущего каталога. Последующий параметр представляет вектор (с завершающим нулевым символом), содержащий аргументы командной строки, представленные в виде строк с завершающими нулевыми символами. Всего может быть n аргументов. Этот вектор завершается NULL-указателем. Элементу arg[] можно присвоить значение таким образом:

char *const arg[] = {«traverse»,".», ">",«1000»,NULL};

Вот пример вызова этой функции:

execv(«traverse», arg) ;

В этом случае утилита traverse перечислит все файлы в текущем каталоге, размер которых превышает 1000 байт.

• int execve(const char *path,char *const arg[],char *const envp[]);

Эта функция аналогична функции execv(), с одним отличием: она имеет дополнительный параметр, envp[], который описан выше.

• int execvp(const char *file,char *const arg[]);

Здесь file — имя выполняемой программы. Последующий параметр представляет собой вектор (с завершающим нулевым символом), содержащий аргументы командной строки, представленные в виде строк с завершающими нулевыми символами. Всего может быть n аргументов. Этот вектор завершается NULL-указателем.

Вот примеры применения синтаксиса функций execv () с различными аргументами:

char *const arg[] = {«traverse»,".», ">",«1000»,NULL};

char *const envp[] = {«files=50»,NULL};

execv("/path/traverse», arg);

execve("/path/traverse», arg, envp);

execvp(«traverse», arg);

Здесь в каждом примере вызова execv-функции активизированный процесс выполняет программу traverse.

Определение ограничений для функций exec ()

Существуют ограничения на размеры вектора argv[] и массива envp[], передаваемые функциям семейства exec. Для определения максимального размера аргументов командной строки и размера переменных среды при использовании exec-функций (которые принимают параметр envp [ ]) можно использовать функцию sysconf (). Чтобы эта функция возвратила размер, ее параметру name необходимо присвоить значение _SC_ARG_МАХ.

Синопсис

#include <unistd.h>

long sysconf(int name);

Еще одним ограничением при использовании функций семейства exec и других Функций, применяемых для создания процессов, является максимальное количество одновременно выполняемых процессов, которое допустимо для одного пользователя.

Чтобы функция sysconf() возвратила это число, ее параметру name необходимо присвоить значение _SC_CHILD_MAX.

Чтение и установка переменных среды

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

$НОМЕ Полное составное имя каталога пользователя.

$РАТН Список каталогов для поиска выполняемых файлов при выполнении команд.

$MAIL Полное составное имя почтового ящика пользователя.

$USER Идентификатор (id) пользователя.

$SHELL Полное составное имя командной оболочки зарегистрированного пользователя.

$TERM Тип терминала пользователя.

Переменные среды могут храниться в файле или в списке, принадлежащем среде. Этот список среды содержит указатели на строки с завершающими нулевыми символами. Когда процесс начинает выполняться, переменная extern char **environ

будет указывать на список среды. Строки, составляющие список среды, имеют следующий формат: name=value

Процессы, инициализированные с помощью функций execl(), execlp(), execv() и execvp(), наследуют конфигурацию среды родительского процесса. Процессы, инициализированные с помощью функций execve() и execle(), сами устанавливают среду.

Существуют функции и утилиты, которые позволяют опросить, добавить или модифицировать переменные среды. Функция getenv() используется для определения факта установки заданной переменной. Интересующая вас переменная задается с помощью параметра name. Если заданная переменная не установлена, функция возвращает значение NULL. В противном случае (если переменная установлена), функция возвращает указатель на строку, содержащую ее значение.

Синопсис

#include <stdlib.h>

char *getenv(const char *name);

int setenv(const char *name, const char *value,

int overwrite); void unsetenv(const char *name);

Рассмотрим пример:

string Path; Path = getenv(«PATH»);

Здесь строке Path присваивается значение, содержащееся во встроенной переменной среды РАТН.

функция setenv() используется для изменения значения существующей переменной среды или добавления новой переменной в среду вызывающего процесса. Параметр name содержит имя переменной среды, которую надлежит добавить или изменить. Заданной переменной присваивается значение, переданное в параметре value. Если переменная, заданная параметром name, уже существует, ее прежнее значение заменяется значением, заданным параметром value при условии, если параметр overwrite содержит ненулевое значение. Если же значение overwrite равно 0, содержимое заданной переменной среды не модифицируется. Функция setenv () возвращает 0 при успешном выполнении, в противном случае — значение -1. функция unsetenv () удаляет переменную среды, заданную параметром name.

3.6.4. Использование функции system() для порождения процессов

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

Синопсис

#include <stdlib.h>

int system(const char *string);

В качестве параметра string можно передать системную команду или имя выполняемого файла. При удачном исходе функция возвращает статус завершения команды или значение, возвращаемое программой (если таковое предусмотрено). Ошибки могут возникнуть на нескольких уровнях, т.е. ошибка может произойти при выполнении функции fork() или exec() либо заданная оболочка может оказаться неподходящей для выполнения команды или программы.

Функция system () возвращает значение родительскому процессу. При неудачном исходе функции exec() возвращается число 127, а при обнаружении других ошибок — число -1. Эта функция не влияет на состояние ожидания сыновних процессов.

Использование POSIX-функций для порождения процессов

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

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

• стратегия планирования;

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

• идентификатор пользователя и группы;

• маска сигналов.

Функции posix_spawn() позволяют управлять тем, будут ли сигналы, проигнорированные родительским процессом, игнорироваться его потомком или устанавливаться для выполнения действий, заданных по умолчанию. Управление дескрипторами файлов позволяет сыновнему процессу получить самостоятельный доступ к потоку данных, независимо открытому родителем. Возможность установить для сыновнего процесса идентификатор группы повлияет на то, как управление сыновней задачей будет связано с управлением родителем. Наконец, стратегию планирования сыновнего процесса можно установить отличной от стратегии планирования его родителя.

Синопсис

#include <spawn.h>

int posix_spawn( pid_t *restrict pid, const char *restrict path,

const posix_spawn_file_actions_t *file_actions,

const posix_spawnattr_t *restrict attrp,

char *const argv[restrict],

char *const envp[restrict]);

int posix_spawnp(pid_t *restrict pid, const char *restrict file,

const posix_spawn_file_actions_t *file_actions,

const posix_spawnattr_t *restrict attrp,

char *const argv[restrict],

char *const envp[restrict]);

Различие между этими двумя функциями состоит в том, что функции posix_spawn () передается параметр path, а функции posix_spawnp () — параметр file. Параметр path в функции posix_spawn() принимает полное или относительное составное имя выполняемого файла, а параметр file в функции posix_spawnp () — только имя выполняемой программы. Если этот параметр содержит символ «косая черта», то содержимое параметра file используется в качестве составного путевого имени. В противном случае путь к выполняемому файлу определяется с помощью переменной среды PATH .

Параметр file_actions представляет собой указатель на структуру posix_spawn_file_actions_t:

struct posix_spawn_file_actions_t {

int _allocated;

int _used;

struct _spawn_action *actions;

int _pad[16] ;

} ;

Структура posix_spawn_file_actions_t содержит информацию о действиях, выполняемых в новом процессе над дескрипторами файлов. Параметр file_actions используется для преобразования родительского набора дескрипторов открытых файлов в набор дескрипторов файлов для порожденного сыновнего процесса. Эта структура может содержать ряд файловых операций, предназначенных для выполнения в последовательности, в которой они были добавлены в объект действий над файлами. Эти файловые операции выполняются над дескрипторами открытых файлов родительского процесса и позволяют копировать, добавлять, удалять или закрывать дескрипторы заданных файлов от имени сыновнего процесса даже до его создания. Если параметр file_actions содержит нулевой указатель, то дескрипторы файлов, открытые родительским процессом, останутся открытыми для его потомка без каких-либо модификаций. Функции, используемые для добавления действий над файлами в объект типа posix_spawn_file_actions, перечислены в табл. 3.4.

Таблица З.4. Функции, используемые для добавления действий над файлами в объект типа posix_spawn_file_actions

int posix_spawn_file_actions_addclоse (posix_spawn_file_actions_t *file_actions, int fildes);

Добавляет действие close() в объект действий над файлами, заданный параметром file_actions. В результате при порождении нового процесса с помощью этого объекта будет закрыт файловый дескриптор fildes

int posix_spawn_file_actions_addopen (posix_spawn_file_actions_t *file_actions, int fildes,

const char *restrict path, int oflag, mode_t mode);

Добавляет действие open () в объект действий над файлами, заданный параметром file_actions. В результате при порождении нового процесса с помощью этого объекта будет открыт файл, заданный параметром path, с использованием дескриптора fildes

int posix_spawn_file_actions_adddup2 (posix_spawn_file_actions_t *file_actions, int fildes, int new fildes);

Добавляет действие dup2 () в объект действий над файлами, заданный параметром file_actions. В результате при порождении нового процесса с помощью этого объекта будет создан дубликат файлового дескриптора fildes с использованием файлового дескриптора newfildes

int posix_spawn_file_actions_destroy(posix_spawn_file_actions_t *file_actions);

Разрушает объект, заданный параметром file_actions, что приводит к деинициализации этого объекта. Затем его можно инициализировать повторно с помощью функции posix_spawn_file_actions_init ()

int posix_spawn_file_actions_init (posix_spawn_file_actions_t *file_actions);

Инициализирует объект, заданный параметром file_actions. После инициализации этот объект не будет содержать действий, предназначенных для выполнения над файлами

Параметр attrp указывает на структуру posix_ spawnattr_t:

struct posix_spawnattr_t {

short int _flags;

pid_t _pgrp;

sigset__t _sd;

sigset_t _ss;

struct sched_param _sp;

int _policy;

int _pad[16] ;

};

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

_flags Используется для индикации того, какие атрибуты процесса должны быть модифицированы в порожденном процессе.

Эти атрибуты организованы поразрядно по принципу включающего ИЛИ:

POSIX_SPAWN_RESETIDS

POSIX_SPAWN_SETPGROUP

POSIX_SPAWN_SETSIGDEF

POSIX_SPAWN_SETSIGMASK

POSIX_SPAWN_SETSCHEDPARAM

POSIX_SPAWN_SETSCHEDULER

_pgrp Идентификатор группы процессов, подлежащих объединению с новым

процессом.

_sd Представляет множество сигналов, подлежащих обработке по умолчанию новым процессом.

_ss Представляет маску сигналов, подлежащую использованию новым процессом.

_sp Представляет параметр планирования, подлежащий назначению новому процессу.

_policy Представляет стратегию планирования, предназначенную для нового процесса.

Функции, используемые для установки и считывания отдельных атрибутов, содержащихся в структуре posix_spawnattr_t, перечислены в табл. 3.5.

Таблица 3.5. Функции, используемые для установки и считывания отдельных атрибутов структуры posix_spawnattr_t

int posix_spawnattr_getflags(const posix_spawnattr_t *restrict attr, short *restrict flags); Возвращает значение атрибута _flags, хранимого в объекте, заданном параметром attr

int posix_spawnattr_setflags (posix_spawnattr_t *attr,short flags); Устанавливает значение атрибута _flags, хранимого в объекте, заданном параметром attr, равным значению параметра flags

int posix_spawnattr_getpgroup (const posix_spawnattr_t *restrict attr, pid_t *restrict pgroup); Возвращает значение атрибута _pgroup, хранимого в объекте, заданном параметром attr, и сохраняет его в параметре pgroup

int posix_spawnattr_setpgroup (posix_spawnattr_t *attr, pid_t pgroup); Устанавливает значение атрибута_pgroup, хранимого в объекте, заданном параметром attr, равным параметру pgroup, если в атрибуте _flags установлен признак POSIX_S PAWN_SETPGROUP

int posix_spawnattr_getschedparam (const posix_spawnattr_t *restrict attr, struct sched_param *restrict schedparam) ; Возвращает значение атрибута_sp, хранимого в объекте, заданном параметром attr, и сохраняет его в параметре schedparam

int posix_spawnattr_setschedparam (posix_spawnattr_t *attr, const struct sched_param *restrict schedparam) ; Устанавливает значение атрибута_sp, хранимого в объекте, заданном параметром attr, равным параметру schedparam, если в атрибуте _flags установлен признак POSIX_SPAWN_SETSCHEDPARAM

int posix_spawnattr_getschedpolicy (const posix_spawnattr_t *restrict attr, int *restrict schedpolicy) ; Возвращает значение атрибута _policy, хранимого в объекте, заданном параметром attr, и сохраняет его в параметре schedpolicy

int posix_spawnattr_setschedpolicy (posix_spawnattr_t *attr, int schedpolicy); Устанавливает значение атрибута_policy, хранимого в объекте, заданном параметром attr, равным параметру schedpolicy, если в атрибуте_flags установлен признак POSIX_SPAWN_SETSCHEDULER

int posix_spawnattr_getsigdefault (const posix_spawnattr_t *restrict attr, sigset_t *restrict sigdefault); Возвращает значение атрибута_sd, хранимого в объекте, заданном параметром attr, и сохраняет его в параметре sigdefault

int posix_spawnattr_setsigdefault (posix_spawnattr_t *attr, const sigset_t *restrictsigdefault); Устанавливает значение атрибута_sd, хранимого в объекте, заданном параметром attr, равным параметру sigdefault, если в атрибуте _flags установлен признак POSIX_SPAWN_SETSIGDEF

int p osix_spawnattr_getsigmask (const posix_spawnattr_t *restrict attr, sigset_t *restrict sigmask); Возвращает значение атрибута _ss, хранимого в объекте, заданном параметром attr, и сохраняет его в параметре sigmask

int posix_spawnattr_setsigmask (posix_spawnattr_t *restrict attr, const sigset_t *restrict sigmask); Устанавливает значение атрибута_ss, хранимого в объекте, заданном параметром attr, равным параметру sigmask, если в атрибуте _flags установлен признак POSIX_S PAWN_SETSIGMASK

int posix_spawnattr_destroy (posix_spawnattr_t *attr); Разрушает объект, заданный параметром attr. Этот объект можно затем снова инициализировать с помощью функции posix_spawnattr_init()

int posix_spawnattr_init (posix_spawnattr_t *attr);Инициализирует объект, заданный параметром attr, значениями, действующими по умолчанию для всех атрибутов, содержащихся в этой структуре

Пример использования функции posix_spawn () для создания процесса приведен в листинге 3.3.

// Листинг 3.3. Порождение процесса с помощью // функции posix_spawn(), которая

// вызывает утилиту ps

#include <spawn.h>

#include <stdio.h>

#include <errno.h>

#include <iostream>

{

//...

posix_spawnattr_t X;

posix_spawn_file_actions_t Y;

pid_t Pid;

char *const argv[] = {"/bin/ps»,«-lf»,NULL};

char *const envp[] = {«PROCESSES=2»};

posix_spawnattr_init(&X);

posix_spawn_file_actions_init(&Y);

posix_spawn(&Pid,"/bin/ps»,&Y,&X,argv,envp);

perror(«posix_spawn»);

cout << «spawned PID: " << Pid << endl;

//...

return(0);

}

В листинге 3.3 инициализируются объекты posix_spawnattr_t и posix_spawn_ file_actions_t. Функция posix_spawn() вызывается с такими аргументами: Pid,путь " /bin/ps», Y, X, массив argv (который содержит команду в качестве первого элемента и опцию в качестве второго) и массив envp, содержащий список переменных среды. При успешном выполнении функции posix_spawn() значение, хранимое в параметре Pid, станет идентификатором (PID) порожденного процесса, а функция perror() отобразит следующий результат:

posix_spawn: Success

Затем будет выведено значение Pid. В данном случае порожденный процесс выполняет следующую команду: /bin/ps -lf

При успешном выполнении POSIX-функции возвращают (обычным путем) число 0 и в параметре pid идентификатор (id) сыновнего процесса (для родительского процесса). В случае неудачи сыновний процесс не создается, следовательно, значение pid не имеет смысла, а сама функция возвращает значение ошибки.

При использовании spawn-функций ошибки могут возникать на трех уровнях. Во-первых, это возможно, если окажутся недействительными объекты file_actions или attr objects. Если это произойдет после успешного (казалось бы) завершения функции (т.е. после порождения сыновнего процесса), такой сыновний процесс может получить статус завершения со значением 127 . Если ошибка связана с функциями управления атрибутами порожденных процессов, возвращается код ошибки, сгенерированный конкретной функцией (см. табл. 3.4 и 3.5). Если spawn -функция успела успешно завершиться, то сыновний процесс может иметь статус завершения со значением 127 .

Ошибки также возникают при попытке породить сыновний процесс. Эти ошибки будут такими же, как при выполнении функций fork () или exec (). В этом случае они (ошибки) займут место значений, возвращаемых spawn -функциями. Если сыновний процесс генерирует ошибку, родительский процесс не получает «дурного известия» автоматически. Для извещения родителя об ошибке сыновнего процесса необходимо использовать другие механизмы, поскольку информация об этом не сохраняется в статусе завершения потомка. С этой целью можно использовать механизм межпроцессного взаимодействия либо специальный флаг, устанавливаемый сыновним процессом и видимый для его родителя.

Идентификация родительских и сыновних процессов с помощью функций управления процессами

Существуют две функции, которые возвращают значение идентификатора (PID) вызывающего процесса и значение идентификатора (PPID) родительского процесса. Функция getpid () возвращает идентификатор вызывающего процесса, а функция getppid() — идентификатор процесса, который является родительским для вызывающего процесса. Эти функции всегда завершаются успешно, поэтому коды ошибок не определены.

Синопсис

#include <unistd.h>

pid_t getpid(void);

pid_t getppid(void);

Завершение процесса

Когда процесс завершается, его блок БУП разрушается, а используемое им адресное пространство и ресурсы освобождаются. Код завершения помещается в главную таблицу процессов. Как только родительский процесс примет этот код, соответствующая структура таблицы процессов будет удалена. Процесс завершается, если соблюдены следующие требования.

• Все инструкции выполнены.

• Процесс явным образом передает управление родительскому процессу или вызывает системную функцию, которая завершает процесс.

• Сыновние процессы могут завершаться автоматически при завершении родительского процесса.

• Родительский процесс посылает сигнал о завершении своих сыновних процессов.

Аварийное завершение процесса может произойти в случае, если процесс выполняет недопустимые действия.

• Процесс требует больше памяти, чем система может ему предоставить.

• Процесс пытается получить доступ к неразрешенным ресурсам.

• Процесс пытается выполнить некорректную инструкцию или запрещенные вычисления.

Завершение процесса может быть инициировано пользователем, если этот процесс является интерактивным.

Родительский процесс несет ответственность за завершение (освобождение) своих потомков. Родительский процесс должен ожидать до тех пор, пока не завершатся все его сыновние процессы. Если родительский процесс выполнит считывание кода завершения сыновнего процесса, процесс-потомок покидает систему нормально. Процесс остается в «зомбированном» состоянии до тех пор, пока его родитель не примет соответствующий сигнал. Если родитель никогда не примет сигнал (поскольку он уже успел сам завершиться и выйти из системы или не ожидал завершения сыновнего процесса), процесс-потомок остается в «зомбированном» состоянии до тех пор, пока процесс init (исходный системный процесс) не примет его код завершения. Большое количество «зомбированных» процессов может негативно отразиться на производительности системы.

Функции exit (), kill () и abort ()

Для самостоятельного завершения процесс может вызвать одну из двух функций: exit() и abort(). Функция exit() обеспечивает нормальное завершение вызывающего процесса. При этом будут закрыты все дескрипторы открытых файлов, связанные с процессом. Функция exit () сбросит на диск все открытые потоки, содержащие еще не переписанные буферизованные данные, после чего открытые потоки будут закрыты. Параметр status принимает статус завершения процесса, возвращаемый ожидающему родительскому процессу, который затем перезапускается. Параметр status может принимать такие значения: 0 , EXIT_FAILURE или EXIT_SUCCESS. Значение 0 говорит об успешном завершении процесса. Ожидающий родительский процесс имеет доступ только к младшим восьми битам значения параметра status. Если родительский процесс не ожидает завершения сыновнего процесса, его (ставшего «зомбированным») «усыновляет» процесс init.

Функция abort () вызывает аварийное окончание вызывающего процесса, что по последствиям равноценно результату выполнения функции fclose() для всех открытых потоков. При этом ожидающий родительский процесс получит сигнал о прекращении выполнения сыновнего процесса. Процесс может прибегнуть к преждевременному прекращению только в случае, если он обнаружит ошибку, с которой не сможет справиться программным путем.

Синопсис

#include <stdlib.h>

void exit(int status);

void abort(void) ;

Функцию kill() можно использовать для принудительного завершения другого процесса. Эта функция отправляет сигнал процессам, заданным параметром pid. Параметр sig — это сигнал, предназначенный для отправки заданному процессу. Возможные сигналы перечислены в заголовке <signal.h>. Для уничтожения процесса параметр sig должен иметь значение SIGKILL. Чтобы иметь право отсылать сигнал процессу, вызывающий процесс должен обладать соответствующими привилегиями, либо его реальный или идентификатор эффективного пользователя должен совпадать с реальным или сохраненным пользовательским идентификатором процесса, который принимает этот сигнал. Вызывающий процесс может иметь разрешение на отправку процессам только определенных (а не любых) сигналов. При успешной отправке сигнала функция возвращает вызывающему процессу значение 0, в противном случае — число -1.

Вызывающий процесс может отправить сигнал одному или нескольким процессам при таких условиях.

pid > 0 Сигнал будет отослан процессу, идентификатор (PID) которого равен значению параметра pid.

pid = 0 Сигнал будет отослан всем процессам, у которых идентификатор группы процессов совпадает с идентификатором вызывающего процесса.

pid = -1 Сигнал будет отослан всем процессам, для которых вызывающий процесс имеет разрешение отправлять этот сигнал.

pid < -1 Сигнал будет отослан всем процессам, у которых идентификатор группы процессов равен абсолютному значению параметра pid, и для которых вызывающий процесс имеет разрешение отправлять этот сигнал.

Синопсис

#include <signal.h>

int kill(pid_t pid, int sig)

Ресурсы процессов

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

Чтобы процесс получил доступ к ресурсу, он должен сначала сделать запрос, обратившись с ним к операционной системе. Если ресурс свободен, операционная система позволит процессу его использовать. После использования ресурса процесс освобождает его, чтобы он стал доступным для других процессов. Если ресурс недоступен, запрос отвергается, и процесс должен подождать его освобождения. Как только ресурс станет доступным, процесс активизируется. Таков базовый подход к распределению ресурсов между процессами. На рис. 3.11 показан граф распределения ресурсов, по которому можно понять, какие процессы удерживают ресурсы, а какие их ожидают. Так, процесс В делает запрос на ресурс 2, который удерживается процессом С. Процесс С делает запрос на ресурс 3, который удерживается процессом D.

Рис. 3.11. Граф распределения ресурсов, который показывает, какие процессы удерживают ресурсы, а какие их запрашивают

Если удовлетворяется сразу несколько запросов на получение доступа к ресурсу, этот ресурс является совместно используемым, или разделяемым (эта ситуация также отображена на рис. 3.11). Процесс А разделяет ресурс R 1 с процессом D. Разделяемые ресурсы могут допускать параллельный доступ сразу нескольких процессов или разрешать доступ только одному процессу в течение ограниченного промежутка времени, после чего аналогичным доступом сможет воспользоваться другой процесс. Примером такого типа разделяемых ресурсов может служить процессор. Сначала процессор назначается одному процессу в течение короткого интервала времени, а затем процессор «получает» другой процесс. Если удовлетворяется только один запрос на получение доступа к ресурсу, и это происходит после того, как ресурс освободит другой процесс, такой ресурс является неразделяемым, а о процессе говорят, что он имеет монопольный доступ (exclusive access) к ресурсу. В многопроцессорной среде важно знать, какой доступ можно организовать к разделяемому ресурсу: параллельный или последовательный (передавая «эстафету» поочередно от ресурса к ресурсу). Это позволит избежать ловушек, присущих параллелизму.

Одни ресурсы могут изменяться или модифицироваться процессами, а другие^ нет. Поведение разделяемых модифицируемых или немодифицируемых ресурсов определяется типом ресурса.

§ 3.1 • Граф распределения ресурсов ,

Графы распределения ресурсов — это направленные графы, которые показывают, как распределяются ресурсы в системе. Такой граф состоит из множества вершин V множества ребер E. Множество вершин делится на две категории:

P = {P 1 , P 2 ,..., Pn)

R = {R 1 , R 2 ,..., Rm}

Множество P— это множество всех процессов, а R— это множество всех ресурсов в системе Ребро, направленное от процесса к ресурсу, называется ребром запроса, а ребро, направленное от ресурса к процессу, называется ребром назначения. Направленные ребра обозначаются следующим образом:

P i → R j Ребро запроса: процесс Р i запрашивает экземпляр типа ресурса R j

R j → P i . Ребро назначения: экземпляр типа ресурса R j выделен процессу P i ;

Каждый процесс в графе распределения ресурсов отображается кругом, а каждый ресурс — прямоугольником. Поскольку может быть много экземпляров одного типа ресурса, то каждый из них представляется точкой внутри прямоугольника. Ребро запроса указывает на периметр прямоугольника ресурса, а ребро назначения берет начало из точки и касается периметра круга процесса.

Граф распределения ресурсов, показанный на рис. 3.11, отображает следующее.

Множества P, R и E

P={P a , P b , P c , P d }

R={R 1 ,R 2 ,R 3 }

E = {R 1 → P a , R 1 → P d , P b → R 2 , R 2 → P c , P c → R 3 , R 3 → P d }

Типы ресурсов

Существуют три основных типа ресурсов: аппаратные, информационные и программные. Аппаратные ресурсы представляют собой физические устройства, подключенные к компьютеру (например, процессоры, основная память и все устройства ввода-вывода, включая принтеры, жесткий диск, накопитель на магнитной ленте, дисковод с zip-архивом, мониторы, клавиатуры, звуковые, сетевые и графические карты, а также модемы. Все эти устройства могут совместно использовать несколько процессов.

Некоторые аппаратные ресурсы прерываются [7], чтобы разрешить доступ к ним различных процессов. Например, прерывания процессора позволяют различным процессам выполняться по очереди. Оперативное запоминающее устройство, или ОЗУ (RAM),- это еще один пример ресурса, разделяемого посредством прерываний. Когда процесс не выполняется, некоторые страничные блоки, которые он занимает, могут быть выгружены во вспомогательное запоминающее устройство, а на их место загружены данные, относящиеся к другому процессу. В любой момент времени весь диапазон памяти может быть занят страничными блоками только одного процесса.

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

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

Разделяемые библиотеки могут служить примером программных ресурсов. Разделяемые библиотеки предоставляют общий набор функций для процессов. Процессы могут также совместно использовать приложения, программы и утилиты. В этом случае в памяти находится только одна копия программного кода , например, приложения (приложений). При этом должны существовать отдельные копии данных , по одной для каждого пользователя (процесса). К неизменяемому программному коду (который также именуется реентерабельным, или повторно используемым) могут получать доступ несколько процессов одновременно.

POSIX-функции для установки ограничений доступа к ресурсам

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

• размер стека процесса;

• размер создаваемого файла и файла ядра;

• объем времени ЦП, выделенный процессу (размер кванта времени);

• объем памяти, используемый процессом;

• количество дескрипторов открытых файлов.

Операционная система устанавливает жесткие ограничения на использование ресурсов процессом. Процесс может установить или изменить мягкие ограничения ресурсов, но это значение не должно превысить жесткий предел, установленный операционной системой. Процесс может понизить свой жесткий предел, но его значение не должно быть меньше мягкого предела. Операция по понижению процессом своего жесткого предела необратима. Его могут повысить только процессы, обладающие специальными привилегиями.

Синопсис

#include <sys/resource.h>

int setrlimit(int resource, const struct rlimit *rlp);

int getrlimit(int resource, struct rlimit *rlp);

int getrusage(int who, struct rusage *r_usage);

Функция setrlimit() используется для установки ограничений на потребление заданных ресурсов. Эта функция позволяет установить как жесткий, так и мягкий пределы. Параметр resource представляет тип ресурса. Значения типов ресурсов (и их краткое описание) приведено в табл. 3.6. Жесткие и мягкие пределы заданного ресурса представляются параметром rlp, который указывает на структуру rlimit, содержащую два объекта типа rlim_t.

struct rlimit {

rlim_t rlim_cur;

rlim_t rlim_max;

} ;

Тип rlim_t — это целочисленный тип без знака. Член rlim_cur содержит значение текущего, или мягкого предела, а член rlim_max — значение максимума, или жесткого предела. Членам rlim_cur и rlim_max можно присвоить любые значения, а также символические константы, определенные в заголовке <sys/resource. h>.

RLIM_INFINITY Отсутствие ограничения.

RLIM_SAVED_MAX Непредставимый хранимый жесткий предел.

RLIM_SAVED_CUR Непредставимый хранимый мягкий предел.

Как жесткий, так и мягкий пределы можно установить равными значению RLIM_INFINITY, которое подразумевает, что ресурс неограничен.

Таблица З.6. Значения параметра resource

RLIMIT_CORE Максимальный размер файла ядра в байтах, который может быть создан процессом

RLIMIT_CPU Максимальный объем времени ЦП в секундах, которое может быть использовано процессом RLIMIT_DATA Максимальный размер раздела данных процесса в байтах

RLIMIT_FSIZE Максимальный размер файла в байтах, который может быть создан процессом

RLlMlT_NOFILE Увеличенное на единицу максимальное значение, которое система может назначить вновь созданному дескриптору файла

RLlMlT_STACK Максимальный размер стека процесса в байтах

RLlMlT_AS  Максимальный размер доступной памяти процесса в байтах

Функция getrlimit () возвращает значения мягкого и жесткого пределов заданного ресурса в объекте rlp. Обе функции возвращают значение 0 при успешном завершении и число -1 в противном случае. Пример установки процессом мягкого предела для размера файлов в байтах приведен в листинге 3.4.

Листинг 3.4. Использование функции setrlimit() для  установки мягкого предела для размера файлов

#include <sys/resource.h>

struct rlimit R_limit;

struct rlimit R_limit_values;

R_limit.rlim_cur = 2 000;

R_limit.rlim_max = RLIM_SAVED_MAX;

setrlimit (RLIMIT_FSIZE, &R__1 imit);

getrlimit(RLIMIT_FSIZE, &R_limit_values);

cout << «мягкий предел для размера файлов: " << R_limit_values.rlim_cur <<endl;

В листинге 3.4 мягкий предел для размера файлов устанавливается равным 2000 байт, а жесткий предел — максимально возможному значению. Функции setrlimit () передаются значения RLIMIT_FSIZE и R_limit, а функции getrlimit () — значения RLIMIT_FSIZE и R_limit_values. После их выполнения на экран выводится установленное значение мягкого предела.

Функция getrusage () возвращает информацию об использовании ресурсов вызывающим процессом. Она также возвращает информацию о сыновнем процессе, завершения которого ожидает вызывающий процесс. Параметр who может иметь следующие значения:

RUSAGE_SELF

RUSAGE_CHILDREN

Если параметру who передано значение RUSAGE_SELF, то возвращаемая информация будет относиться к вызывающему процессу. Если же параметр who содержит значение RUSAGE_CHILDREN, то возвращаемая информация будет относиться к потомку вызывающего процесса. Если вызывающий процесс не ожидает завершения своего потомка, информация, связанная с ним, отбрасывается (не учитывается). Возвращаемая информация передается через параметр r_usage, который указывает на структуру rusage. Эта структура содержит члены, перечисленные и описанные в табл. 3.7. При успешном выполнении функция возвращает число 0, в противном случае — число -1.

Таблица 3.7. Члены структуры rusage

Член структуры   Описание

struct timeval ru_utime Время,потраченное пользователем

struct timeval ru_sutime Время,использованное системой

long ru_maxrss Максимальный размер, установленный для резидентной программы

long ru_maxixrss Размер разделяемой памяти

long ru_maxidrss Размер неразделяемой области данных

long ru_maxisrss Размер неразделяемой области стеков

long ru_minflt Количество запросов на страницы

long ru_maj flt Количество ошибок из-за отсутствия страниц

long ru_nswap Количество перекачек страниц

long ru_inblock Блочные операции по вводу данных

long ru_oublock Блочные операции операций по выводу данных

long ru_msgsnd Количество отправленных сообщений

long ru_msgrcv Количество полученных сообщений

long ru_nsignals Количество полученных сигналов

long ru_nvcsw Количество преднамеренных переключений контекста

long ru_nivcsw Количество принудительных переключений контекста

Асинхронные и синхронные процессы

Асинхронные процессы выполняются независимо один от другого. Это означает, что процесс А будет выполняться до конца безотносительно к процессу В. Между асинхронными процессами могут быть прямые родственные («родитель-сын») отношения, а могут и не быть. Если процесс А создает процесс В, они оба могут выполняться независимо, но в некоторый момент родитель должен получить статус завершения сыновнего процесса. Если между процессами нет прямых родственных отношений, у них может быть общий родитель.

Асинхронные процессы могут выполняться последовательно, параллельно или с перекрытием. Эти сценарии изображены на рис. 3.12. В ситуации 1 до самого конца выполняется процесс А, затем процесс В и процесс С выполняются до самого конца. Это и есть последовательное выполнение процессов. В ситуации 2 процессы выполняются одновременно. Процессы А и В - активные процессы. Во время выполнения процесса А процесс В находится в состоянии ожидания. В течение некоторого интервала времени оба процесса пребывают в ждущем режиме. Затем процесс В «просыпается», причем раньше процесса А, а через некоторое время «просыпается» и процесс А, и теперь оба процесса выполняются одновременно. Эта ситуация показывает, что асинхронные процессы могут выполняться одновременно только в течение определенных интервалов времени. В ситуации 3 выполнение процессов А и В перекрывается.

Рис. 3.12. Возможные сценарии асинхронных и синхронных процессов

Асинхронные процессы могут совместно использовать такие ресурсы, как файлы или память. Это может потребовать (или не потребовать) синхронизации или взаимодействия при разделении ресурсов. Если процессы выполняются последовательно (ситуация 1), то они не потребуют никакой синхронизации. Например, все три процесса, А, В и С, могут разделять некоторую глобальную переменную. Процесс А (перед тем как завершиться) записывает значение в эту переменную, затем процесс В во время своего выполнения считывает данные, хранимые в этой переменной и (перед тем как завершиться) записывает в нее «свое» значение. Затем во время своего выполнения процесс С считывает данные из этой переменной. Но в ситуациях 2 и 3 процессы могут попытаться одновременно модифицировать эту переменную, поэтому здесь не обойтись без синхронизации доступа к ней.

Мы определяем синхронные процессы как процессы с перемежающимся выполнением, когда один процесс приостанавливает свое выполнение до тех пор, пока не з аверш ится другой - Например, процесс А, родительский, при выполнении создает процесс В, сыновний. Процесс А приостанавливает свое выполнение до тех пор, пока не завершится процесс В. После завершения процесса В его выходной код помещается в таблицу процессов. Тем самым процесс А уведомляется о завершении процecca В. Процесс А может продолжить выполнение, а затем завершиться или завершиться немедленно. В этом случае выполнение процессов А и В является синхронизированным. Сценарий синхронного выполнения процессов А и В (для сравнения с асинхронным) также показан на рис. 3.12.

Создание синхронных и асинхронных процессов с помощью функций fork (), exec (), system () и posix_spawn()

Функции fork (), fork-exec и posix_spawn () позволяют создавать асинхронные процессы. При использовании функции fork() дублируется образ родительского процесса. После создания сыновнего процесса эта функция возвращает родителю (через параметр) идентификатор (PID) процесса-потомка и (обычным путем) число 0, означающее, что создание процесса прошло успешно. При этом родительский процесс не приостанавливается; оба процесса продолжают выполняться независимо от инструкции, следующей непосредственно за вызовом функции fork (). При создании сыновнего процесса посредством fork-exec-комбинации его образ инициализируется с помощью образа нового процесса. Если функция exec () выполнилась успешно (т.е. успешно прошла инициализация), она не возвращает родительскому процессу никакого значения. Функции posix_spawn() создают образы сыновних процессов инициализируют их. Помимо идентификатора (PID), возвращаемого (через параметр) функцией posix_spawn() родительскому процессу, обычным путем возвращается значение, служащее индикатором успешного порождения процесса. После выполнения функции posix_spawn() оба процесса выполняются одновременно. Функция system() позволяет создавать синхронные процессы. При этом создается оболочка, которая выполняет системную команду или запускает выполняемый файл. В этом случае родительский процесс приостанавливается до тех пор, пока не завершится сыновний процесс и функция system () не возвратит значение.

Функция wait ()

Асинхронный процесс, вызвав функцию wait (), может приостановить выполнение до тех пор, пока не завершится сыновний процесс. После завершения сыновнего процесса ожидающий родительский процесс считывает статус завершения своего потомка, чтобы не допустить создания процесса- «зомби». Функция wait () получает статус завершения из таблицы процессов. Параметр status указывает на ту область, которая содержит статус завершения сыновнего процесса. Если родительский процесс имеет не один, а несколько сыновних процессов и некоторые из них уже завершились, функция wait () считывает из таблицы процессов статус завершения только для одного сыновнего процесса. Если информация о статусе окажется доступной еще до вып олнения функции wait (), эта функция завершится немедленно. Если родительский процесс не имеет ни одного потомка, эта функция возвратит код ошибки.

Функцию wait () можно использовать также в том случае, когда вызывающий процесс должен ожидать до тех пор, пока не получит сигнал, чтобы затем выполнить определенные действия по его обработке.

Синопсис

#include <sys/wait.h>

pid_t wait(int *status);

pid_t waitpid(pid_t pid, int *status, int options);

Функция waitpid() аналогична функции wait () за исключением того, что она принимает дополнительные параметры pid и options. Параметр pid задает множество сыновних процессов, для которых считывается статус завершения. Другими словами, значение параметра pid определяет, какие процессы попадают в это множество.

pid > 0 Единственный сыновний процесс.

pid = 0 Любой сыновний процесс, групповой идентификатор которого совпадает с идентификатором вызывающего процесса.

pid < -1 Любые сыновние процессы, групповой идентификатор которых равен абсолютному значению pid.

pid = -1 Любые сыновние процессы.

Параметр options определяет, как должно происходить ожидание процесса, и может принимать одно из значений следующих констант, определенных в заголовке <sys/wait .h>:

WCONTINUED Сообщает статус завершения любого продолженного сыновнего процесса (заданного параметром pid), о статусе которого не было доложено с момента продолжения его выполнения.

WUNTRACED Сообщает статус завершения любого остановленного сыновнего процесса (заданного параметром pid), о статусе которого не было доложено с момента его останова.

WNOHANG  Вызывающий процесс не приостанавливается, если статус завершения заданного сыновнего процесса недоступен.

Эти константы могут быть объединены с помощью логической операции ИЛИ и переданы в качестве параметра options (например, WCONTINUED | WUNTRACED).

Обе эти функции возвращают идентификатор (PID) сыновнего процесса, для которого получен статус завершения. Если значение, содержащееся в параметре status, равно числу 0, это означает, что сыновний процесс завершился при таких условиях:

• процесс вернул значение 0 из функции main ();

• процесс вызвал некоторую версию функции exit() с аргументом 0;

• процесс был завершен, поскольку завершился последний поток процесса.

В табл. 3.8 перечислены макросы, которые позволяют вычислить значение статуса завершения.

Таблица З.8. Макросы, которые позволяют вычислить значение статуса завершения

WIFEXITED Приводится к ненулевому значению, если статус был возвращен нормально завершенным сыновним процессом

WEXITSTATUS Если значение WIFEXITED оказывается ненулевым, то оцениваются младшие 8 бит аргумента status, переданного завершенным сыновним процессом функции _exit () или exit (), либо значения, возвращенного функцией main ()

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

WTERMSIG Если значение WIFSIGNALED оказывается ненулевым, то оценивается номер сигнала, который послужил причиной завершения сыновнего процесса

WIFSTOPPED Приводится к ненулевому значению, если статус был возвращен от сыновнего процесса, который в данный момент остановлен

WSTOPSIG Если значение WIFSTOPPED оказывается ненулевым, то оценивается номер сигнала, который послужил причиной останова сыновнего процесса

WIFCONTINUED Приводится к ненулевому значению, если статус был возвращен от сыновнего процесса, который продолжил выполнение после сигнала останова, принятого от блока управления заданиями

Разбиение программы на задачи

Рассматривая разбиение программы на несколько задач, вы делаете первый шаг к внесению параллелизма в свою программу. В однопроцессорной среде параллелизм реализуется посредством многозадачности. Это достигается путем переключения процессов. Каждый процесс выполняется в течение некоторого короткого интервала времени, после чего процессор «передается» другому процессу. Это происходит настолько быстро, что создается иллюзия одновременного выполнения процессов. В многопроцессорной среде процессы, принадлежащие одной программе, могут быть назначены одному или различным процессорам. Процессы, назначенные различным процессорам, выполняются параллельно.

Различают два уровня параллельной обработки в приложении или системе: уровень процессов и уровень потоков. Параллельная обработка на уровне потоков носит название многопоточности (она рассматривается в следующей главе). Чтобы разумно разделить программу на параллельные задачи, необходимо определить, где «гнездится» параллелизм и где можно воспользоваться преимуществами от его реализации. Иногда в параллелизме нет насущной необходимости. Программа может интерпретироваться с учетом параллелизма, но и при последовательном выполнении действий она прекрасно работает. Безусловно, внесение параллелизма может повысить ее быстродействие и понизить уровень сложности. Одни программы обладают естественным параллелизмом, а другим больше подходит последовательное выполнение действий. Программы также могут иметь двойственную интерпретацию.

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

Задачи, на которые будет разделена программа, могут выполняться параллельно, причем здесь можно выделить следующие три способа реализации параллелизма.

1. Выделение в программе одной основной задачи, которая создает некоторое количество подзадач.

2. Разделение программы на множество отдельных выполняемых файлов.

3. Разделение программы на несколько задач разного типа, отвечающих за создание других подзадач только определенного типа.

Эти способы реализации параллелизма отображены на рис. 3.13.

Например, эти методы реализации параллелизма можно применить к программе визуализации. Под визуализацией будем понимать процесс перехода от представления трехмерного объекта в форме записей базы данных в двухмерную теневую графическую проекцию на поверхность отображения (экран дисплея). Изображение представляется в виде теневых многоугольников, повторяющих форму объекта. Этапы визуализации показаны на рис. 3.14. Визуализацию можно разбить на ряд отдельных задач.

1. Установить структуру данных для сеточных моделей многоугольников.

2. Применить линейные преобразования.

3. Отбраковать многоугольники, относящиеся к невидимой поверхности.

4. Выполнить растеризацию.

5. Применить алгоритм удаления скрытых поверхностей.

6. Затушевать отдельные пиксели.

Первая задача состоит в представлении объекта в виде массива многоугольников, в котором каждая вершина многоугольника описывается в трехмерной мировой системе координат. Вторая задача — применить линейные преобразования к сеточной модели многоугольников. Эти преобразования используются для позиционирования объектов на сцене и создания точки обзора или поверхности отображения (области, которая видима наблюдателю с его точки обзора). Третья задача — отбраковать невидимые поверхности объектов на сцене. Это означает удаление линий, принадлежащих тем частям объектов, которые невидимы с точки обзора. Четвертая задача — преобразовать модель вершин в набор координат пикселей. Пятая задача — удалить любые скрытые поверхности. Если сцена содержит взаимодействующие объекты, например, когда одни объекты заслоняют другие, то скрытые (передними объектами) поверхности должны быть удалены. Шестая задача - наложить на поверхности изображения тень.

Рис. 3.13. Способы разбиения программы на отдельные задачи

Рис. 3.14. Этапы визуализации

Решение каждой задачи представляется в виде отдельного выполняемого файла. Первые три задачи (Taskl, Task2 и Task3) выполняются последовательно, а остальные три (Task4, Task5 и Task6)— параллельно. Реализация первого способа создания программы визуализации приведена в листинге 3.5.

// Листинг 3.5. Использование способа 1 для создания процессов

#include <spawn.h>

#include <stdlib.h>

#include <stdio.h>

#include <sys/wait.h>

#include <errno.h>

#include <unistd.h>

int main(void) {

posix_spawnattr_t Attr;

posix_spawn_file_actions_t FileActions;

char *const argv4[] = {«Task4»,...,NULL};

char *const argv5[] = {«Task5'\...,NULL};

char *const argv6[] = {«Task6»,...,NULL};

pid_t Pid;

int stat;

// Выполняем первые три задачи синхронно,

system(«Taskl . . . ") ;

system(«Task2 . . . ") ;

system(«Task3 . . . ") ;

//иниииализируем структуры

posix_spawnattr_init(&Attr);

posix_spawn_file_actions_init(&FileActions);

// execute last 3 tasks asynchronously

posix_spawn(&Pid,«Task4»,&FileActions,&Attr,argv4,NULL);

posix_spawn(&Pid,«Task5»,&FileActions,&Attr,argv5,NULL);

posix_spawn(&Pid,«Task6»,&FileActions,&Attr,argv6,NULL);

// like a good parent, wait for all your children

wait (&stat);

wait (&stat);

wait (&stat);

return(0);

}

В листинге 3.5 из функции main () с помощью функции system( ) вызываются на выполнение задачи Task1, Task2 и Task3. Каждая из них выполняется синхронно с родительским процессом. Задачи Task4, Task5 и Task6 выполняются асинхронно родительскому процессу благодаря использованию функций posix__spawn( ). Многоточие (... ) используется для обозначения файлов, требуемых задачам. Родительский процесс вызывает три функции wait (), и каждая из них ожидает завершения одной из задач (Task4, Task5 или Task6).

Используя второй способ, программу визуализации можно запустить из сценария командной оболочки. Преимущество этого сценария состоит в том, что он позволяет использовать все команды и операторы оболочки. В нашей программе визуализации для управления выполнением задач используются метасимволы & и &&.

Task1 ... && Task2 ... && Task3 Task4 . . . & Task5 . . . & Task6

Здесь благодаря использованию метасимвола && задачи Task1, Task2 и Task3 выполняются последовательно при условии успешного выполнения предыдущей задачи. Задачи же Task4, Task5 и Task6 выполняются одновременно, поскольку использован метасимвол &. Приведем некоторые метасимволы, применяемые при разделении команд в средах UNIX/Linux, и способы выполнения этих команд.

&& Каждая следующая команда будет выполняться только в случае успешного выполнения предыдущей команды.

|| Каждая следующая команда будет выполняться только в случае неудачного выполнения предыдущей команды.

; Команды должны выполняться последовательно.

& Все команды должны выполняться одновременно.

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

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

•  задачи, которые выполняют растеризацию: вычерчивание линий; заливка участков сплошного фона; растеризация многоугольников;

•  задачи, которые выполняют удаление поверхностей: удаление скрытых поверхностей; удаление невидимых поверхностей;

•  задачи, которые выполняют наложение теней: затенение отдельных пикселей; затенение изображения в целом.

Разбиение задач по категориям позволяет нашей программе приобрести более общий характер. Процессы при необходимости создают другие процессы, предназначенные для выполнения действий только определенной категории. Например, если нашей программе предстоит визуализировать лишь один объект, а не всю сцену, то нет никакой необходимости порождать процесс, который выполняет удаление скрытых поверхностей; вполне достаточно будет удаления невидимых поверхностей (одного объекта). Если объект не нужно затенять, то нет необходимости порождать задачу, выполняющую наложение тени; обязательным остается лишь линейное преобразование при решении задачи растеризации. Для запуска программы с использованием третьего способа можно использовать родительский процесс или сценарий оболочки. Родительский процесс может определить, какой нужен тип визуализации, и передать соответствующую информацию каждому из специализированных процессов, чтобы они «знали», какие процессы им следует порождать. Эта информация может быть также перенаправлена каждому из специализированных процессов из сценария оболочки. Реализация третьего способа представлена в листинге 3.6.

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

// создания процессов. Задачи запускаются из

// родительского процесса

#include <spawn.h>

#include <stdlib.h>

#include <stdio.h>

#include <sys/wait.h>

#include <errno.h>

#include <unistd.h>

int main(void) {

posix_spawnattr_t Attr;

posix_spawn_file_actions_t FileActions;

pid_t Pid;

int stat;

//•••

system(«Task1 ...»);// Выполняется безотносительно к типу используемой визуализации.

//определяем, какой нужен тип визуализации. Это можно

// сд елать, получив информацию от пользователя или

// выполнив специальный анализ.

// затем сообщаем о результате другим задачам с помощью

// аргументов.

char *const argv4[] = {«TaskType4»,...,NULL};

char *const argv5[] = {«TaskType5»,...,NULL};

char *const argv6[] = {«TaskType6»,...,NULL}

system(«TaskType2 . . . ");

system(«TaskType3 . . . ");

// Инициализируем структуры.

posix_spawnattr_init(&Attr) ;

posix_spawn_file_actions_init (&FileActions) ;

posix_spawn(&Pid, «TaskType4», &FileActions,&Attr,argv4, NULL);

posix_spawn(&Pid, «TaskType5», &FileActions,&Attr,argv5, NULL);

if(Y){

posix_spawn(&Pid,«TaskType6»,&FileActions,&Attr, argv6,NULL);

}

// Подобно хорошему родителю, ожидаем возвращения // своих «детей».

wait(&stat);

wait(&stat);

wait(&stat);

return(0);

}

// Все TaskType-задачи должны быть аналогичными. //.. .

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

int Rt; //. . .

if(argv[1] == X){

// Инициализируем структуры.

posix_spawn(&Pid,«TaskTypeX»,&FileActions,&Attr,..., NULL);

else{

// Инициализируем структуры.

//.. •

posix_spawn(&Pid,«TaskTypeY», &FileActions,&Attr, ...,NULL);

}

wait(&stat); exit(0);

}

В листинге 3.6 тип каждой задачи (а следовательно, и тип порождаемого процесса) определяется на основе информации, передаваемой от родительского процесса или сценария оболочки.

Линии видимого контура

Порождение процессов, как показано в листинге 3.7, возможно с помощью функций, вызываемых из функции main ().

// Листинг 3.7. Стержневая ветвь программы, из которой // вызывается функция, порождающая процесс

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

Rt = funcl(X, Y, Z); //.. .

}

// Определение функции.

int funcl(char *M, char *N, char *V) {

//.. .

char *const args[] = {«TaskX»',M,N,V,NULL};

Pid = fork();

if(Pid == 0) {

exec(«TaskX»,args);

}

if(Pid > 0) {

//.. .

}

wait(&stat);

}

В листинге 3.7 функция funcl () вызывается с тремя аргументами. Эти аргументы передаются порожденному процессу.

Процессы также могут порождаться из методов, принадлежащих объектам. Как показано в листинге 3.8, объекты можно объявить в любом процессе.

// Лист инг 3.8. Объявление объекта в процессе //-••

my_pbject MyObject; //-••

// Объявление и определение класса.

class my_object {

public: //...

int spawnProcess(int X); //...

};

int my_object::spawnProcess(int X) {

//.. .

// posix__spawn() или system() //.. .

}

Как показано в листинге 3.8, объект может создавать любое количество процессов из любого метода.

Резюме

Параллелизм в С++-программе достигается за счет ее разложения на несколько процессов или несколько потоков. Процесс- это «единица работы», создаваемая операционной системой. Если программа- это артефакт (продукт деятельности) разработчика, то процесс - это артефакт операционной системы. Приложение может состоять из нескольких процессов, которые могут быть не связаны с какой-то конкретной программой. Операционные системы способны управлять сотнями и даже тысячами параллельно загруженных процессов.

Некоторые данные и атрибуты процесса хранятся в блоке управления процессами (process control block - PCB), или БУП, используемом операционной системой для идентификации процесса. С помощью этой информации операционная система Управляет процессами. Многозадачность (выполнение одновременно нескольких процессов) реализуется путем переключения контекста. Текущее состояние выполняемого процесса и его контекст сохраняются в БУП-блоке, что позволяет успешно возобновить этот процесс в следующий раз, когда он будет назначен центральному процессору. Занимая процессор, процесс пребывает в состоянии выполнения, а когда он ожидает использования ЦП, - то в состоянии готовности (ожидания). Получить информацию о процессах, выполняющихся в системе, можно с помощью утилиты ps.

Процессы, которые создают другие процессы, вступают с ними в «родственные» (отцы- и -дети) отношения. Создатель процесса называется родительским, а созданный процесс — сыновним. Сыновние процессы наследуют от родительских множество атрибутов. «Святая обязанность» родительского процесса — подождать, пока сыновний не покинет систему. Для создания процессов предусмотрены различные системные функции: fork (), fork-exec (), system() и posix_spawn (). Функции fork(), fork-exec() и posix_spawn() создают процессы, которые являются асинхронными, в то время как функция system() создает сыновний процесс, который является синхронным по отношению к родительскому. Асинхронные родительские процессы могут вызвать функцию wait (), после чего «синхронно» ожидать, пока сыновние процессы не завершатся или пока не будут считаны коды завершения для уже завершившихся сыновних процессов.

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

Разбиение C++ программ на множество потоков

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

— Эндрю Кёниг и Барбара My(Andrew Koening and Barbara Moo), Ruminations on С++

Работу любой последовательной программы можно разделить между несколькими подпрограммами. Каждой подпрограмме назначается конкретная задача, и все эти задачи выполняются одна за другой. Вторая задача не может начаться до тех пор, пока не завершится первая, а третья — пока не закончится вторая и т.д. Описанная схема прекрасно работает до тех пор, пока не будут достигнуты границы производительности и сложности. В одних случаях единственное решение проблемы производительности — найти возможность выполнять одновременно более одной задачи. В других ситуациях работа подпрограмм в программе настолько сложна, что имеет смысл представить эти подпрограммы в виде мини-программ, которые выполняются параллельно внутри основной программы. В главе 3 были представлены методы разбиения одной программы на несколько процессов, каждый из которых выполняет отдельную задачу. Такие методы позволяют приложению в каждый момент времени выполнять сразу несколько действий. Однако в этом случае каждый процесс имеет собственные адресное пространство и ресурсы. Поскольку каждый процесс занимает отдельное адресное пространство, то взаимодействие между процессами превращается в настоящую проблему. Для обеспечения связи между раздельно выполняемыми частями общей программы нужно реализовать такие средства межпроцессного взаимодействия, как каналы, FIFO-очереди (с дисциплиной обслуживания по принципу «первым пришел — первым обслужен») и переменные среды. Иногда нужно иметь одну программу (которая выполняет несколько задач одновременно), не разбивая ее на множество мини-программ. В таких обстоятельствах можно использовать потоки. Потоки позволяют одной программе состоять из параллельно выполняемых частей, причем все части имеют доступ к одним и тем же переменным, константам и адресному пространству в целом. Потоки можно рассматривать как мини-программы в основной программе. Если программа разделена на несколько процессов, как было показано в главе 3 , то с выполнением каждого отдельного процесса связаны определенные затраты системных ресурсов. Для потоков требуется меньший объем затрат системных ресурсов. Поэтому потоки можно рассматривать как облегченные процессы, т.е. они позволяют воспользоваться многими преимуществами процессов без больших затрат на организацию взаимодействия между ними. Потоки обеспечивают средства разделения основного «русла» программы на несколько параллельно выполняемых «ручейков».

Определение потока

Под потоком подразумевается часть выполняемого кода в UNIX- или Linux-процессе, которая может быть регламентирована определенным образом. Затраты вычислительных ресурсов, связанные с созданием потока, его поддержкой и управлением, у операционной системы значительно ниже по сравнению с аналогичными затратами для процессов, поскольку объем информации отдельного потока гораздо меньше, чем у процесса. Каждый процесс имеет основной, или первичный, поток. Под основным потоком процесса понимается программный поток управления или поток выполнения. Процесс может иметь несколько потоков выполнения и, соответственно, столько же потоков управления. Каждый поток, имея собственную последовательность инструкций, выполняется независимо от других, а все они — параллельно друг другу. Процесс с несколькими потоками, называется многопоточным. Многопоточный процесс, состоящий из нескольких потоков, показан на рис. 4.1.

Рис. 4.1. Потоки выполнения многопоточного процесса

Контекстные требования потока

Все потоки одного процесса существуют в одном и том же адресном пространстве. Все ресурсы, принадлежащие процессу, разделяются между потоками. Потоки не владеют никакими ресурсами. Ресурсы, которыми владеет процесс, совместно используются всеми потоками этого процесса. Потоки разделяют дескрипторы файлов и файловые указатели, но каждый поток имеет собственные программный указатель, набор регистров, состояние и стек. Все стеки потоков находятся в стековом разделе своего процесса. Раздел данных процесса совместно используется потоками процесса. Поток может считывать (и записывать) информацию из области памяти своего процесса. Когда основной поток записывает данные в память, то любые сыновние потоки могут получить к ним доступ. Потоки могут создавать другие потоки в пределах того же процесса. Все потоки в одном процессе считаются равноправными. Потоки также могут приостановить, возобновить или завершить другие потоки в своем процессе.

Потоки — это выполняемые части программы, которые соревнуются за использование процессора с потоками того же самого или других процессов. В многопроцессорной системе потоки одного процесса могут выполняться одновременно на различных процессорах. Однако потоки конкретного процесса выполняются только на процессоре, который назначен этому процессу. Если, например, процессоры 1, 2 и 3 назначены процессу А, а процесс А имеет три потока, то любой из них может быть назначен любому процессору. В среде с одним процессором потоки конкурируют за его использование. Параллельность же достигается за счет переключения контекста. Контекст переключается, если операционная система поддерживает многозадачность при наличии единственного процессора. Многозадачность позволяет на одном процессоре одновременно выполнять несколько задач. Каждая задача выполняется в течение выделенного интервала времени. По истечении заданного интервала или после наступления некоторого события текущая задача снимается с процессора, а ему назначается другая задача. Когда потоки выполняются параллельно в одном процессе, то о таком процессе говорят, что он — многопоточный. Каждый поток выполняет свою подзадачу таким образом, что подзадачи процесса могут выполняться независимо от основного потока управления процесса. При многозадачности потоки могут конкурировать за использование одного процессора или назначаться другим процессорам. Но в любом случае переключение контекста между потоками одного и того же процесса требует меньше ресурсов, чем переключение контекста между потоками различных процессов. Процесс использует много системных ресурсов для отслеживания соответствующей информации, а на управление этой информацией при переключении контекста между процессами требуется значительное время. Большая часть информации, содержащейся в контексте процесса, описывает адресное пространство процесса и ресурсы, которыми он владеет. Переключаясь между потоками, определенными в различных адресных пространствах, контекст переключается и между процессами. Поскольку потоки в рамках одного процесса не имеют собственного адресного пространства (или ресурсов), то операционной системе приходится отслеживать меньший объем информации. Контекст потока состоит только из идентификационного номера (id), стека, набора регистров и приоритета. В регистрах содержится программный указатель и указатель стека. Текст (программный код) потока содержится в текстовом разделе соответствующего процесса. Поэтому переключение контекста между потоками одного процесса займет меньше времени и потребует меньшего объема системных ресурсов.

Сравнение потоков и процессов

У потоков и процессов есть много общего. Они имеют идентификационный номер (id), состояние, набор регистров, приоритет и привязку к определенной стратегии планирования. Подобно процессам, потоки имеют атрибуты, которые описывают их для операционной системы. Эта информация содержится в информационном блоке потока, подобном информационному блоку процесса. Потоки и сыновние процессы разделяют ресурсы родительского процесса. Ресурсы, открытые родительским процессом (в его основном потоке), немедленно становятся доступными всем потокам и сыновним процессам. При этом никакой дополнительной инициализации или подготовки не требуется. Потоки и сыновние процессы независимы от родителя (создателя) и конкурируют за использование процессора. Создатель процесса или потока управляет своим потомком, т.е. он может отменить, приостановить или возобновить его выполнение либо изменить его приоритет. Поток или процесс может изменить свои атрибуты и создать новые ресурсы, но не может получить доступ к ресурсам, принадлежащим другим процессам. Однако между потоками и процессами есть множество различий.

Различия между потоками и процессами

Основное различие между потоками и процессами состоит в том, что каждый процесс имеет собственное адресное пространство, а потоки — нет. Если процесс создает множество потоков, то все они будут содержаться в его адресном пространстве. Вот почему они так легко разделяют общие ресурсы, и так просто обеспечивается взаимодействие между ними. Сыновние процессы имеют собственные адресные пространства и копии разделов данных. Следовательно, когда процесс-потомок изменяет свои переменные или данные, это не влияет на данные родительского процесса. Если необходимо, чтобы родительский и сыновний процессы совместно использовали данные, нужно создать общую область памяти. Для передачи данных между родителем и потомком используются такие механизмы межпроцессного взаимодействия, как каналы и FIFO-очереди. Потоки одного процесса могут передавать информацию и связываться друг с другом путем непосредственного считывания и записи общих данных, которые доступны родительскому процессу.

Потоки, управляющие другими потоками

В то время как процессы могут управлять другими процессами, если между ними установлены отношения типа «родитель-потомок», потоки одного процесса считаются равноправными и находятся на одном уровне, независимо от того, кто кого создал. Любой поток, имеющий доступ к идентификационному номеру (id) некоторого другого потока, может отменить, приостановить, возобновить выполнение э того потока либо изменить его приоритет. Отмена основного потока приведет к завершению всех потоков процесса, т.е. к ликвидации процесса. Любые изменения, внесенные в основной поток, могут повлиять на все потоки процесса. При изменении приоритета процесса все его потоки, которые унаследовали этот приоритет, должны также изменить свои приоритеты. Сходства и различия между потоками и процессами сведены в табл. 4.1.

Таблица 4.1. Сходства и различия между потоками и процессами

Сходства

• Оба имеют идентификационный номер (id), состояние, набор регистров, приоритет и привязку

к определенной стратегии планирования

• И поток, и процесс имеют атрибуты, которые описывают их особенности для операционной системы

• Как поток, так и процесс имеют информационные блоки

• Оба разделяют ресурсы с родительским процессом

• Оба функционируют независимо от родительского процесса

• Их создатель может управлять потоком или процессом

• И поток, и процесс могут изменять свои атрибуты

• Оба могут создавать новые ресурсы

• Как поток, так и процесс не имеют доступа к ресурсам другого процесса

Различия

• Потоки разделяют адресное пространство процесса, который их создал; процессы имеют собственное адресное пространство

• Потоки имеют прямой доступ к разделу данных своего процесса; процессы имеют собственную копию раздела данных родительского процесса

• Потоки могут напрямую взаимодействовать

с другими потоками своего процесса; процессы должны использовать специальный механизм межпроцессного взаимодействия для связи с «братскими» процессами

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

• Новые потоки создаются легко; новые процессы требуют дублирования родительского процесса

• Потоки могут в значительной степени управлять потоками того же процесса; процессы управляют только сыновними процессами

• Изменения, вносимые в основной поток (отмена, изменение приоритета и т.д.), могут влиять на поведение других потоков процесса; изменения, вносимые в родительский процесс, не влияют на сыновние процессы

Преимущества использования потоков

При управлении подзадачами приложения использование потоков имеет ряд преимуществ.

• Для переключения контекста требуется меньше системных ресурсов.

• Достигается более высокая производительность приложения.

• Для обеспечения взаимодействия между задачами не требуется никакого специального механизма.

• Программа имеет более простую структуру.

Переключение контекста при низкой (ограниченной) доступности процессора

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

Возможности повышения производительности приложения

Создание нескольких потоков повышает производительность приложения. При использовании одного потока запрос к устройствам ввода-вывода может остановить весь процесс. Если же в приложении организовано несколько потоков, то пока один из них будет ожидать удовлетворения запроса ввода-вывода, другие потоки, которые не зависят от заблокированного, смогут продолжать выполнение. Тот факт, что не все потоки ожидают завершения операции ввода-вывода, означает, что приложение в целом не заблокировано ожиданием, а продолжает работать.

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

Потоки не требуют специального механизма взаимодействия между подзадачами. Потоки могут напрямую передавать данные другим потокам и получать данные от них, что также способствует экономии системных ресурсов, которые при использовании нескольких процессов пришлось бы направлять на настройку и поддержку специальных механизмов взаимодействия. Потоки же используют общую память, выделяемую в адресном пространстве процесса. Процессы также могут взаимодействовать через общую память, но они имеют раздельные адресные пространства, и поэтому такая общая память должна быть вне адресных пространств обоих взаимодействующих процессов. Этот подход увеличит временные и пространственные расходы системы на поддержку и доступ к общей памяти. Схема взаимодействия между потоками и процессами показана на рис. 4 .2 .

Упрощение структуры программы

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

Недостатки использования потоков

Простота доступности потоков к памяти процесса имеет свои недостатки.

• Потоки могут легко разрушить адресное пространство процесса.

• Потоки необходимо синхронизировать при параллельном доступе (для чтения или записи) к памяти.

• Один поток может ликвидировать целый процесс или программу.

• Потоки существуют только в рамках единого процесса и, следовательно, не являются многократно используемыми.

Рис. 4.2. Взаимодействие между потоками одного процесса и взаимодействие между несколькими процессами

Потоки могут легко разрушить адресное пространство процесса

Потоки могут легко разрушить информацию процесса во время «гонки» данных, если сразу несколько потоков получат доступ для записи одних и тех же данных. При использовании процессов это невозможно. Каждый процесс имеет собственные данные, и другие процессы не в состоянии получить к ним доступ, если не сделать это специально. Защита информации обусловлена наличием у процессов отдельных адресных пространств. Тот факт, что потоки совместно используют одно и то же адресное пространство, делает данные незащищенными от искажения. Например, процесс имеет три потока — А, В и С. Потоки А и В записывают информацию в некоторую область памяти, а поток С считывает из нее значение и использует его для вычислений. Потоки А и В могут попытаться одновременно записать информацию в эту область памяти. Поток В может перезаписать данные, записанные потоком А, еще до того, как поток С получит возможность считать их. Поведение этих потоков должно быть синхронизировано таким образом, чтобы поток С мог считать данные, записанные потоком А, до того, как поток В их перезапишет. Синхронизация защищает данные от перезаписи до их использования. Тема синхронизации потоков рассматривается в главе 5.

Один поток может ликвидировать целую программу

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

Потоки не могут многократно использоваться другими программами

Потоки зависят от процесса, в котором они существуют, и их невозможно от него отделить. Процессы отличаются большей степенью независимости, чем потоки. Приложение можно так разделить на задачи, порученные процессам, что эти процессы можно оформить в виде модулей, которые возможно использовать в других приложениях. Потоки не могут существовать вне процессов, в которых они были созданы и, следовательно, они не являются повторно используемыми. Преимущества и недостатки потоков сведены в табл. 4.2.

Анатомия потока

Образ потока встраивается в образ процесса. Как было описано в главе 3, процесс имеет разделы программного кода, данных и стеков. Поток разделяет разделы кода и данных с остальными потоками процесса. Каждый поток имеет собственный стек, выделенный ему в стековом разделе адресного пространства процесса. Размер потокового стека устанавливается при создании потока. Если создатель потока не определяет размер его стека, то система назначает размер по умолчанию. Размер, устанавливаемый по умолчанию, зависит от конкретной системы, максимально возможного количества потоков в процессе, размера адресного пространства, выделяемого процессу, и пространства, используемого системными ресурсами. Размер потокового стека должен быть достаточно большим для любых функций, вызываемых потоком, любого кода, который является внешним по отношению к процессу (например, это Может быть библиотечный код), и хранения локальных переменных. Процесс с несколькими потоками должен иметь стековый раздел, который будет вмещать все стеки его потоков. Адресное пространство, выделенное для процесса, ограничивает раз-Мер стека, ограничивая тем самым размер, который может иметь каждый поток. На Рис.4.3 показана схема процесса, который содержит два потока.

Как показано на рис. 4.3, процесс содержит два потока А и В, и их стеки располо жены в стековом разделе процесса. Потоки выполняют различные функции: поток А вы п олняет функцию func1(), а поток В - функцию func2().

Рис. 4.3. Схема процесса, содержащего два потока (SP — указатель стека, PC — счетчик команд)

Таблица 4.2. Преимущества и недостатки потоков

Преимущества потоков

Для переключения контекста требуется меньше системных ресурсов

Потоки способны повысить производительность приложения

Для обеспечения взаимодействия между потоками никакого специального механизма не требуется

Благодаря потокам структуру программы можно упростить

Недостатки потоков

Для параллельного доступа к памяти (чтения или записи данных) требуется синхронизация

Потоки могут разрушить адресное пространство своего процесса

Потоки существуют в рамках только одного процесса, поэтому их нельзя повторно использовать

Атрибуты потока

Атрибуты процесса содержат информацию, которая описывает процесс для операционной системы. Операционная система использует эту информацию для управления процессами, а также для того, чтобы отличать один процесс от другого. Процесс совместно использует со своими потоками практически все, включая ресурсы и переменные среды. Разделы данных, раздел программного кода и все ресурсы связаны с процессом, а не с потоками. Все, что нужно для функционирования потока, определяется и предоставляется процессом. Потоки же отличаются один от другого идентификационным номером (id), набором регистров, определяющих состояние потока, его приоритетом и стеком. Именно эти атрибуты формируют уникальность каждого потока. Как и при использовании процессов, информация о потоках хранится в структурах данных и возвращается функциями, поддерживаемыми операционной системой. Например, часть информации о потоке содержится в структуре, именуемой информационным блоком потока, который создается вместе с потоком.

Идентификационный номер (id) потока — это уникальное значение, которое идентифицирует каждый поток во время его существования в процессе. Приоритет потока определяет, каким потокам предоставлен привилегированный доступ к процессору в выделенное время. Под состоянием потока понимаются условия, в которых он пребывает в любой момент времени. Набор регистров для потока включает программный счетчик и указатель стека. Программный счетчик содержит адрес инструкции, которую поток должен выполнить, а указатель стека ссылается на вершину стека потока.

Библиотека потоков POSIX определяет объект атрибутов потока, инкапсулирующий свойства потока, к которым его создатель может получить доступ и модифицировать их. Объект атрибутов потока определяет следующие компоненты:

• область видимости;

• размер стека;

• адрес стека;

• приоритет;

• состояние;

• стратегия планирования и параметры.

Объект атрибутов потока может быть связан с одним или несколькими потоками. При использовании этого объекта поведение потока или группы потоков определяется профилем. Все потоки, которые используют объект атрибутов, приобретают все свойства, определенные этим объектом. На рис. 4.3 показаны атрибуты, связанные с каждым потоком. Как видите, оба потока (А и В) разделяют объект атрибутов, но они поддерживают свои отдельные идентификационные номера и наборы регистров. После того как объект атрибутов создан и инициализирован, его можно использовать в любых обращениях к функциям создания потоков. Следовательно, можно создать группу потоков, которые будут иметь «малый стек и низкий приоритет» или «большой стек, высокий приоритет и состояние открепления». Открепленный (detached) поток — это поток, который не синхронизирован с другими потоками в процессе. Иначе говоря, не существует потоков, которые бы ожидали до тех пор, пока завершит выполнение открепленный поток. Следовательно, если уж такой поток существует, то его ресурсы (а именно id потока) немедленно принимаются на повторное использование. [8] Для установки и считывания значений этих атрибутов предусмотрены специальные методы. После создания потока его атрибуты нельзя изменить до тех пор, пока он существует.

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

Таблица 4.3. Члены объекта атрибутов потока

Атрибуты

Функции

Описание

detachstate

int pthread_attr_ setdetachstate (pthread_attr_t *attr, int detachstate);

Атрибут detachstate определяет, является ли новый поток открепленным. Если это соответствует истине, то его нельзя объединить ни с каким другим потоком

guardsize

int pthread_attr_ setguardsize (pthread_attr_t *attr, size_t guardsize)

Атрибут guardsize позволяет управлять размером защитной области стека нового потока. Он создает буферную зону размером guardsize на переполненяемом конце стека

inheritsched

int pthread_attr_ setinheritsched (pthread_attr_t *attr, int inheritsched)

Атрибут inheritsched определяет, как будут установлены атрибуты планирования для нового потока, т.е. будут ли они унаследованы от потока-создателя или установлены атрибутным объектом

param

int pthread_attr_ setschedparam (pthread_attr_t *restrict attr, const struct sched_param *restrict param);

schedpolicy

int pthread_attr_ setschedpolicy (pthread_attr_t *attr, int policy);

contentionscope

int pthread_attr_ setscope (pthread_attr_t *attr, int contentionscope);

stackaddr

int pthread_attr_ setstackaddr (pthread_attr_t *attr, void *stackaddr);

int pthread_attr_ setstack (pthread_attr_t

*attr, void *stackaddr, size_t stacksize)j

stacksize

int pthread_attr_ setstacksize (pthread_attr_t *attr, size_t stacksize),

int pthread_attr_ setstack (pthread_attr_t *attr, void *stackaddr, size_t stacksize)j

Атрибут param— это структура, которую можно использовать для установки приоритета нового потока

Атрибут schedpolicy определяет стратегию планирования создаваемого потока

Атрибут contentionscope определяет, с каким множеством потоков будет соперничать создаваемый поток за использование процессорного времени. Область видимости процесса означает, что поток будет состязаться со множеством потоков одного процесса, а область видимости системы означает, что поток будет состязаться с потоками в масштабе всей системы (т.е. сюда входят потоки других процессов)

Атрибуты stackaddr и stacksize определяют базовый адрес и минимальный размер (в байтах) стека, выделяемого для создаваемого потока, соответственно

Атрибут stackaddr определяет базовый адрес стека, выделяемого для создаваемого потока

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

Планирование потоков

Когда подходит время для выполнения процесса, процессор занимает один из его оков. Если процесс имеет только один поток, то именно он (т.е. основной поток) назначается процессору. Если процесс содержит несколько потоков и в системе есть достаточно е количе ство процессоров, то процессорам назначаются все потоки. Потоки соперничают-за процессор либо со всеми потоками из активного процесса системы, либо только

с потоками из одного процесса. Потоки помещаются в очереди готовых потоков, отсортированные по значению их приоритета. Потоки с одинаковым приоритетом назначаются процессорам в соответствии с некоторой стратегией планирования. Если система не содержит достаточного количества процессоров, поток с более высоким приоритетом может выгрузить поток, выполняющийся в данный момент. Если новый активный поток принадлежит тому же процессу, что и выгруженный, возникает переключение контекста потоков. Если же новый активный поток «родом» из другого процесса, то сначала происходит переключение контекста процессов, а затем — контекста потоков.

Состояния потоков

Потоки имеют такие же состояния и переходы между ними (см. главу 3), как и процессы. Диаграмма состояний, показанная на рис. 4.4, — это копия диаграммы, изображенной на рис. 3.4 из главы 3. (Вспомним, что процесс может пребывать в одном из четырех состояний: готовности, выполнения, останова и ожидания, или блокирования.) Состояние потока — это режим или условия, в которых поток существует в данный момент. Поток находится в состоянии готовности (работоспособности), когда он готов к выполнению. Все готовые к работе потоки помещаются в очереди готовности, причем в каждой такой очереди содержатся потоки с одинаковым приоритетом. Когда поток выбирается из очереди готовности и назначается процессору, он (поток) переходит в состояние выполнения. Поток снимается с процессора, если его квант времени истек, или если перешел в состояние готовности поток с более высоким приоритетом. Выгруженный поток снова помещается в очередь готовых потоков. Поток пребывает в состоянии ожидания, если он ожидает наступления некоторого события или завершения операции ввода-вывода. Поток прекращает выполнение, получив сигнал останова, и остается в этом состоянии до тех пор, пока не получит сигнал продолжить работу.

Рис. 4.4. Состояния потоков и переходы между ними

При получении этого сигнала поток переходит из состояния останова в состояние готовности. Переход потока из одного состояния в другое является своего рода сигналом о наступлении некоторого события. Переход конкретного потока из состояния готовности в со стояние выполнения происходит потому, что система выбрала именно его для выполнения, т.е. поток отправляется (dispatched) на процессор. Поток снимается, или выгружается (preempted), с процессора, если он делает запрос на ввод-вывод данных (или какой-либо иной запрос к ядру), или если существуют какие-то причины внешнего характера.

Один поток может определить состояние всего процесса. Состояние процесса с одним потоком синонимично состоянию его основного потока. Если его основной поток находится в состоянии ожидания, значит, и весь процесс находится в состоянии ожидания. Если основной поток выполняется, значит, и процесс выполняется. Что касается процесса с несколькими потоками, то для того, чтобы утверждать, что весь процесс находится в состоянии ожидания или останова, необходимо, чтобы все его потоки пребывали в состоянии ожидания или останова. Но если хотя бы один из его потоков активен (т.е. готов к выполнению или выполняется), процесс считается активным.

Планирование потоков и область конкуренции

Область конкуренции потоков определяет, с каким множеством потоков будет соперничать рассматриваемый поток за использование процессорного времени. Если поток имеет область конкуренции уровня процесса, он будет соперничать за ресурсы с потоками того же самого процесса. Если же поток имеет системную область конкуренции, он будет соперничать за процессорный ресурс с равными ему по правам потоками (из одного с ним процесса) и с потоками других процессов. Пусть, например, как показано на рис. 4.5, существуют два процесса в мультипроцессорной среде, которая включает три процессора. Процесс А имеет четыре потока, а процесс В — три. Для процесса А «расстановка сил» такова: три (из четырех его потоков) имеют область конкуренции уровня процесса, а один— уровня системы. Для процесса В такая «картина»: два (из трех его потоков) имеют область конкуренции уровня процесса, а один— уровня системы. Потоки процесса А с процессной областью конкуренции соперничают за процессор А, а потоки процесса В с такой же (процессной) областью конкуренции соперничают за процессор С. Потоки процессов А и В с системной областью конкуренции соперничают за процессор В.

ПРИМЕЧАНИЕ: потоки при моделировании их реального поведения в приложении Должны иметь системную область конкуренции.

Стратегия планирования и приоритет

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

процессорное время. В операционной системе с приоритетами выполняющийся поток снимается с процессора, если в состояние готовности переходит поток с более высоким приоритетом, обладающий при этом тем же уровнем области конкуренции. Например, как показано на рис. 4.5, потоки с процессной областью конкуренции соревнуются за процессор с потоками того же процесса, имеющими такой же уровень области конкуренции. Процесс А имеет два потока с приоритетом 3, и один из них назначен процессору. Как только поток с приоритетом 2 заявит о своей готовности, активный поток будет вытеснен, а процессор займет поток с более высоким приоритетом. Кроме того, в процессе В есть два потока (процессной области конкуренции) с приоритетом 1 (приоритет 1 выше приоритета 2). Один из этих потоков назначается процессору. И хотя другой поток с приоритетом 1 готов к выполнению, он не вытеснит поток с приоритетом 2 из процесса А, поскольку эти потоки соперничают за процессор в рамках своих процессов. Потоки с системной областью конкуренции и более низким приоритетом не вытесняются ни одним из потоков из процессов А или В. Они соперничают за процессорное время только с потоками, имеющими системную область конкуренции.

Рис. 4.5. Планирование потоков (с процессной и системной областями конкуренции) в мультипроцессорной среде

Как упоминалось в главе 3, очереди готовности организованы в виде отсортированных списков, в которых каждый элемент представляет собой уровень приоритета. Под уровнем приоритета понимается очередь потоков с одинаковым значением приоритета. Все потоки одного уровня приоритета назначаются процессору с использованием стратегии планирования: FIFO (сокр. от First In First OuU т.е. первым прибыл, первым обслужен), RR (сокр. от round-robin, т.е. циклическая) или какой-либо другой. При использовании стратегии планирования FIFO поток, квант процессорного времени которого истек, помещается в головную часть очереди соответствующего приоритетного уровня, а процесс назначается следующему потоку из очереди. Следовательно, поток будет выполняться до тех пор, пока он не завершит выполнение, не перейдет в состояние ожидания («заснет») или не получит сигнал остановиться. Когда «спящий» поток «просыпается», он помещается в конец очереди соответствующего приоритетного уровня. Стратегия планирования RR аналогична FIFO стратегии, за исключением того, что по истечении кванта процессорного времени поток помещается не в начало, а в конец «своей» очереди. Циклическая стратегия планирования (RR) считает все потоки обладающими одинаковыми приоритетами и каждому потоку предоставляет процессор только в течение некоторого кванта времени. Поэтому выполнение задач получается попеременным. Например, программа, которая выполняет поиск файлов по заданным ключевым словам, разбивается на два потока. Один поток (1) находит все файлы с заданным расширением и помещает их пути в контейнер. Второй поток (2) выбирает имена файлов из контейнера, просматривает каждый файл на предмет наличия в нем заданных ключевых слов, а затем записывает имена файлов, которые содержат такие слова. Если к этим потокам применить циклическую стратегию планирования с единственным процессором, то поток 1 использовал бы свой квант времени для поиска файлов и вставки их путей в контейнер. Поток 2 использовал бы свой квант времени для выделения имен файлов и поиска заданных ключевых слов. В идеальном мире потоки 1 и 2 должны выполняться попеременно. Но в действительности все может быть иначе. Например, поток 2 может выполниться до потока 1, когда в контейнере еще нет ни одного файла, или поток 1 может так долго искать файл, что до истечения кванта времени не успеет записать его путь в контейнер. Такая ситуация требует синхронизации, краткое рассмотрение которой приводится ниже в этой главе и в главе 5. Стратегия планирования FIFO позволяет каждому потоку выполняться до завершения. Если рассмотреть тот же пример с использованием FIFO-стратегии, то поток 1 будет иметь достаточно времени, чтобы отыскать все нужные файлы и вставить их пути в контейнер. Поток 2 затем выделит имена файлов и выполнит поиск заданных ключевых слов. В идеальном мире завершение выполнения потока 2 будет означать завершение программы в целом. Но в реальном мире поток 2 может быть назначен процессору до потока 1, когда контейнер еще не будет содержать файлов для поиска в них ключевых слов. После «холостого» выполнения потока 2 процессору будет назначен поток 1, который может успешно отыскать нужные файлы и поместить в контейнер их пути. Однако поиск ключевых слов выполнять уже будет некому. Поэтому программа в целом потерпит фиаско. При использовании FIFO-стратегии не предусматривается перемешивания задач. Поток, назначенный процессору, занимает его До полного выполнения своей задачи. Такую стратегию планирования можно использовать для приложений, в которых потоки необходимо выполнить как можно скорее.

°Д Другими» стратегиями планирования подразумеваются уже рассмотренные, но с небольшими вариациями. Например, FIFO-стратегия может быть изменена таким

разом, чтобы позволить разблокировать потоки, выбранные случайно.

Изменение приоритета потоков

Приоритеты потоков следует менять, чтобы ускорить выполнение потоков, от которых зависит выполнение других потоков. И, наоборот, этого не следует делать ради того, чтобы какой-то конкретный поток получил больше процессорного времени. Это может изменить общую производительность системы. Потоки с более высоким классом приоритета получают больше процессорного времени, чем потоки с более низким классом приоритета, поскольку они выполняются чаще. Потоки с более высоким приоритетом практически монополизируют процессор, не выделяя потокам с более низким приоритетом такое ценное процессорное время. Эта ситуация получила название информационного голода (starvation). Системы, в которых используются механизмы динамического назначения приоритетов, реагируют на подобную ситуацию путем назначения приоритетов, которые бы действовали в течение коротких периодов времени. Система регулирует приоритет потоков таким образом, чтобы потоки с более низким приоритетом увеличили время выполнения. Такой подход должен повысить общую производительность системы.

Гарантировать, что конкретный процесс или поток будет выполняться до его полного завершения, — все равно что присвоить ему самый высокий приоритет. Однако реализация такой стратегии может повлиять на общую производительность системы. Такие привилегированные потоки могут нарушить взаимодействие программных компонентов через сетевые средства коммуникации, вызвав потерю данных. На потоки, которые управляют интерфейсом пользователя, может быть оказано чрезмерно большое влияние, выраженное в замедлении реакции на использование клавиатуры, мыши или экрана. В некоторых системах пользовательским процессам или потокам не назначается более высокий приоритет, чем системным процессам. В противном случае системные процессы или потоки не смогли бы реагировать на критические изменения в системе. Поэтому большинство пользовательских процессов и потоков попадают в категорию программных компонентов с нормальным (средним) приоритетом.

Ресурсы потоков

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

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

Модели создания и функционирования потоков

Цель потока— выполнить некоторую работу от имени процесса. Если процесс содержит несколько потоков, каждый поток выполняет некоторые подзадачи как части общей задачи, выполняемой процессом. Потокам делегируется работа в соответствии с конкретной стратегией, которая определяет, каким образом реализуется делегирование работы. Если приложение моделирует некоторую процедуру или объект, то выбранная стратегия должна отражать эту модель. Используются следующие распространенные модели:

• делегирование («управляющий-рабочий»);

• сеть с равноправными узлами;

• конвейер;

• «изготовитель-потребитель».

Каждая модель характеризуется собственной декомпозицией работ (Work Breakdown Structure — WBS), которая определяет, кто отвечает за создание потоков и при каких условиях они создаются. Например, существует централизованный подход, при котором один поток создает другие потоки и каждому из них делегирует некоторую работу. Существует также конвейерный (assembly-line) подход, при котором на различных этапах потоки выполняют различную работу. Созданные потоки могут выполнять одну и ту же задачу на различных наборах данных, различные задачи на одном и том же наборе данных или различные задачи на различных наборах данных. Потоки подразделяются на категории по выполнению задач только определенного типа. Например, можно создать группы потоков, которые будут выполнять только вычисления, только ввод или только вывод данных.

Возможны задачи, для успешного решения которых следует комбинировать перечисленные выше модели. В главе 3 мы рассматривали процесс визуализации. За-Дачи 1, 2 и 3 выполнялись последовательно, а задачи 4, 5 и 6 могли выполняться параллельно. Все задачи можно выполнить различными потоками. Если необходимо визуализировать несколько изображений, потоки 1, 2 и 3 могут сформировать конвейер. По завершении потока 1 изображение передается потоку 2, в то время к ак поток 1 может выполнять свою работу над следующим изображением. После буферизации изображений потоки 4, 5 и 6 могут реализовать параллельную обработку. Модель функционирования потоков представляет собой часть структурирования па раллелизма в приложении, в котором каждый поток может выполняться на отдельном процессоре. Модели функционирования потоков (и их краткое описание) приведены в табл. 4.4.

Таблица 4.4. Модели функционирования потоков

Модель

Описание

Модель делегирования

Модель с равно-правными узлами

Конвейер

Модель

«изготовитель-потребитель "

Центральный поток («управляющий») создает потоки («рабочие»), назначая каждому из них задачу. Управляющий поток может ожидать до тех пор, пока все потоки не завершат выполнение своих задач

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

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

Поток-«изготовитель» готовит данные , потребляемые потоком- «потребителем». Данные сохраняются в блоке памяти, разделяемом потоками — «изготовителем» и «потребителем»

Модель делегирования

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

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

программировать на обработку запросов только определенного типа. Если тип запроса в очереди не совпадает с типом запросов, на обработку которых ориентирован данный поток, то он может снова приостановиться. Главная цель управляю-потока — создать все потоки, поместить задания в очередь и «разбудить» рабочие потоки, когда эти задания станут доступными. Рабочие потоки справляются о наличии запроса в очереди, выполняют назначенную задачу и приостанавливаются сами, если для них больше нет работы. Все рабочие и управляющий потоки выполняются параллельно. Описанные два подхода к построению модели делегирования представлены для сравнения на рис. 4.6.

Модель с равноправными узлами

Если в модели делегирования есть управляющий поток, который делегирует задачи рабочим потокам, то в модели с равноправными узлами все потоки имеют одинаковый рабочий статус. Несмотря на существование одного потока, который изначально создает все потоки, необходимые для выполнения всех задач, этот поток считается рабочим потоком, но он не выполняет никаких функций по делегированию задач. В этой модели нет никакого централизованного потока, но на рабочие потоки возлагается большая ответственность. Все равноправные потоки могут обрабатывать запросы из одного входного потока данных, либо каждый рабочий поток может иметь собственный входной поток данных, за который он отвечает. Входной поток данных может также храниться в файле или базе данных. Рабочие потоки могут нуждаться во взаимодействии и разделении ресурсов. Модель равноправных потоков представлена на рис. 4.7.

Рис. 4.7. Модель равноправных потоков (или модель с равноправными узлами)

Модель конвейера

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

Рис. 4.8. Модель конвейера

Модель «изготовитель-потребитель»

В модели «изготовитель-потребитель» существует поток-«изготовитель», который готовит данные, потребляемые потоком-«потребителем». Данные сохраняются в блоке памяти, разделяемом между потоками «изготовителем» и «потребителем». Поток-изготовитель» должен сначала приготовить данные, которые затем поток-^потребитель» получит. Такому процессу необходима синхронизация. Если поток-изготовитель» будет поставлять данные гораздо быстрее, чем поток-«потребитель» сможет их потреблять, поток-«изготовитель» несколько раз перезапишет результаты, полученные им ранее, прежде чем поток-«потребитель» успеет их обработать. Но если поток-«потребитель» будет принимать данные гораздо быстрее, чем поток-изготовитель» сможет их поставлять, поток-«потребитель» будет либо снова обрабатывать уже обработанные им данные, либо попытается принять еще не подготовленные данные. Модель «изготовитель-потребитель» представлена на рис. 4.9.

Модели SPMD и МРМD для потоков

В каждой из описанных выше моделей потоки вновь и вновь выполняют одну и ту задачу на различных наборах данных или им назначаются различные задачи для выполнения на различных наборах данных. Эти потоковые модели используют схемы (Single-Program, Multiple-Data — одна программа, несколько потоков данных) и MPMD (Multiple-Programs, Multiple-Data — множество программ, множество потоков данных). Эти схемы представляют собой модели параллелизма, которые делят программы на потоки инструкций и данных. Их можно использовать для описания типа работы, которую реализуют потоковые модели с использованием параллелизма. В контексте нашего изложения материала модель MPMD лучше представить как модель MTMD (Multiple-Threads, Multiple-Data— множество потоков выполнения, множество потоков данных). Эта модель описывает систему с различными потоками выполнения (thread), которые обрабатывают различные наборы данных, или потоки данных (stream). Аналогично модель SPMD нам лучше рассматривать как модель STMD (Single-Thread, Multiple-Data — один поток выполнения, несколько потоков данных). Эта модель описывает систему с одним потоком выполнения, который обрабатывает различные наборы, или потоки, данных. Это означает, что различные наборы данных обрабатываются несколькими идентичными потоками выполнения (вызывающими одну и ту же подпрограмму).

Рис. 4.9. Модель конвейера

Как модель делегирования, так и модель равноправных потоков могут использовать модели параллелизма STMD и MTMD. Как было описано выше, пул потоков может выполнять различные подпрограммы для обработки различных наборов данных. Такое поведение соответствует модели MTMD. Пул потоков может быть также настроен на выполнение одной и той же подпрограммы. Запросы (или задания), отсылаемые системе, могут представлять собой различные наборы данных, а не различные задачи. И в этом случае поведение множества потоков, реализующих одни и те же инструкции, но на различных наборах данных, соответствует модели STMD. Модель равноправных потоков может быть реализована в виде потоков, выполняющих одинаковые или различные задачи. Каждый поток выполнения может иметь собственный поток данных или несколько файлов сданными, предназначенных для обработки каждым потоком. В модели конвейера используется МТМГ>модель параллелизма. На разных этапах выполняются различные виды обработки, поэтому в любой момент времени различные совокупности входных данных будут находиться на различных этапах выполнения. Модельное представление конвейера было бы бесполезным, если бы на каждом этапе выполнялась одна и та же обработка. Модели STMD и MTMD представлены на рис. 4.10.

Введение в библиотеку Pthread

Библиотека Pthread предоставляет API-интерфейс для создания и управления потоками в приложении. Библиотека Pthread основана на стандартизированном интерфейсе программирования, который был определен комитетом по выпуску стандартов IEEE в стандарте POSIX 1003.1с. Сторонние фирмы-изготовители придерживаются стандарта POSIX в реализациях, которые именуются библиотеками потоков Pthread или POSIX.

Рис. 4.10. Модели параллелизма STMD и MTMD

Библиотека Pthread содержит более 60 функций, которые можно разделить на следующие категории.

1. Функции управления потоками.

1.1. Конфигурирование потоков.

1.2. Отмена потоков.

1.3. Стратегии планирования потоков.

1.4. Доступ к данным потоков.

1.5. Обработка сигналов.

1.6. Функции доступа к атрибутам потоков.

1.6.1. Конфигурирование атрибутов потоков.

1.6.2. Конфигурирование атрибутов, относящихся к стекам потоков.

1.6.3. Конфигурирование атрибутов, относящихся к стратегиям планирования потоков.

2. Функции управления мьютексами.

2.1. Конфигурирование мьютексов.

2.2. Управление приоритетами.

2.3. Функции доступа к атрибутам мьютексов.

2.3.1. Конфигурирование атрибутов мьютексов.«

2.3.2. Конфигурирование атрибутов, относящихся к протоколам мьютексов.

2.3.3. Конфигурирование атрибутов, относящихся к управлению приоритетами мьютексов.

3. Функции управления условными переменными.

3.1. Конфигурирование условных переменных.

3.2. Функции доступа к атрибутам условных переменных.

3.2.1. Конфигурирование атрибутов условных переменных.

3.2.2. Функции совместного использования условных переменных.

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

Анатомия простой многопоточной программы

Любая простая многопоточная программа должна состоять из основного потока и функций, которые будут выполнять другие потоки. Выбранная для реализации модель создания и функционирования потоков определяет, каким образом в программе будут созда ваться потоки и как будет осуществляться управление ими. Потоки создаются по принципу «все и сразу» или при определенных условиях. Пример простой многопоточной программы, в которой реализована модель делегирования, представлен в листинге 4.1.

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

// простой многопоточной программе

#include <iostream>

#include <pthread.h>

void *task1(void *X) //define task to be executed by ThreadA

{

//...

cout << «Thread A complete» << endl;

}

void *task2(void *X) //define task to be executed by ThreadB

{

//...

cout << «Thread B complete» << endl;

}

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

{

pthread_t ThreadA,ThreadB; // declare threads

pthread_create(&ThreadA,NULL,task1,NULL); // create threads

pthread_create(&ThreadB,NULL,task2,NULL);

// additional processing

pthread_join(ThreadA,NULL); // wait for threads

pthread_join(ThreadB,NULL);

return(0);

}

В листинге 4.1 делается акцент на определении набора инструкций для основного потока. Основным в данном случае является управляющий поток, который объявляет два рабочих потока ThreadA и ThreadB. С помощью функции pthread_create () эти два потока связываются с задачами, которые они должны выполнить (taskl и task2). Здесь (ради простоты примера) эти задачи всего лишь отп равляют сообщение в стандартный выходной поток, но понятно, что они могли бы быть запрограммированы на нечто более полезное. При вызове функции pthread_create () потоки немедленно приступают к выполнению назначенных им задач. Работа функции pthread_join() аналогична работе функции wait() для процессов. Основной поток ожидает до тех пор, пока не завершатся оба рабочих потока. Диаграмма последовательностей, соответствующая листингу 4.1, показана на рис. 4.11. Обратите внимание на то, что происходит с потоками выполнения при вызове функций pthread_create() и pthread_join ().

На рис.4.11 показано, что вызов функции pthread_create() является причиной разветвления, или образования «вилки» в основном потоке выполнения, в результате чего образуются два дополнительных «ручейка» (по одному для каждой задачи), которые выполняются параллельно. Функция pthread_create() завершается сразу же после создания потоков. Эта функция предназначена для создания асинхронных потоков. Это означает, что, как рабочие, так и основной поток, выполняют свои инструкции независимо друг от друга. Функция pthread_join() заставляет основной поток ожидать до тех пор, пока все рабочие потоки завершатся и «присоединятся» к основному.

Рис. 4.11. Диаграмма последовательностей, соответствующая листингу 4.1

Компиляция и компоновка многопоточных программ

Все многопоточные программы, использующие библиотеку потоков POSIX, должны включать заголовок: < pthread.h >

Для компиляции многопоточного приложения в средах UNIX или Linux с помощью компиляторов командной строки g++ или gcc необходимо скомпоновать его с библиотекой Pthreads. Для задания библиотеки используйте опцию -l. Так, команда -lpthread обеспечит компоновку вашего приложения с библиотекой, которая согласуется с многопоточным интерфейсом, определенным стандартом POSIX 1003.1с. Библиотеку Pthread, libpthread.so , следует поместить в каталог, в котором хранится системная стандартная библиотека, обычно это /usr/lib. Если она будет находиться не в стандартном каталоге, то для того, чтобы обеспечить поиск компилятора в заданном каталоге до поиска в стандартных, используйте опцию -L. По команде g++ -о blackboard -L /src/local/lib blackboard.cpp -lpthread компилятор выполнит поиск библиотеки Pthread сначала в каталоге /src/local/lib, а затем в стандартных каталогах.

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

Создание потоков

Библиотека Pthreads используется для создания, поддержки и управления потоками многопоточных программ и приложений. При создании многопоточной программы потоки могут создаваться на любом этапе выполнения процесса, поскольку это — динамические образования. Функция pthread_create() создает новый поток в адресном пространстве процесса. Параметр thread указывает на дескриптор, или идентификатор (id), создаваемого потока. Новый поток будет иметь атрибуты, заданные объектом attr. Созданный поток немедленно приступит к выполнению инструкций, заданных параметром start_routine с использованием аргументов, заданных параметром arg. При успешном создании потока функция возвращает его идентификатор (id), значение которого сохраняется в параметре thread.

Синопсис

#include <pthread.h>

int pthread_create(pthread_t *restrict thread,

const pthread_attr_t *restrict attr,

void *(*start_routine)(void*),

void *restrict arg) ;

Если параметр attr содержит значение NULL, новый поток будет использовать атрибуты, действующие по умолчанию. В противном случае новый поток использует атрибуты, заданные параметром attr при его создании. Если же значение параметра attr изменится после того, как поток был создан, это никак не отразится на его атрибутах. При завершении параметра-функции start_routine завершается и поток, причем так, как будто была вызвана функция pthread_exit() с использованием в качестве статуса завершения значения, возвращаемого функцией start_routine.

При успешном завершении функция возвращает число 0 . В противном случае по-не создается, и функция возвращает код ошибки. Если в системе отсутствуют ресурсы для создания потока, или в процессе достигнут предел по количеству возможных потоков, выполнение функции считается неудачным. Неудачным оно также будет в случае, если атрибут потока задан некорректно или если инициатор вызова потока не имеет разрешения на установку необходимых атрибутов потока.

Приведем примеры создания двух потоков с заданными по умолчанию атрибутами:

pthread_create(&threadA,NULL, taskl,NULL) ;

pthread_create(&threadB,NULL, task2, NULL) ;

Это — два вызова функции pthread_create () из листинга 4 .1. Оба потока создаются с атрибутами, действующими по умолчанию.

В программе 4 .1 отображен основной поток, который передает аргумент из командной строки в функции, выполняемые потоками.

// Программа 4.1

#include <iostream>

#include <pthread.h>

#include <stdlib.h>

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

pthread_t ThreadA,ThreadB;

int N;

if(argc != 2) {

cout << «error» << endl;

exit (1);

}

N = atoi(argv[l]);

pthread_create(&ThreadA,NULL, taskl,&N);

pthread_create(&ThreadB,NULL, task2, &N);

cout « «Ожидание присоединения потоков.» « endl;

pthread_join(ThreadA,NULL) ;

pthread_join(ThreadB,NULL);

return (0) ;

};

В программе 4 .1 показано, как основной поток может передать аргументы из командной строки в каждую из потоковых функций. Число в командной строке имеет строковый тип. Поэтому в основном потоке аргумент сначала преобразуется в целочисленное значение, и только после этого результат преобразования передается при каждом вызове функции pthread_create () посредством ее последнего аргумента.

В программе 4.2 представлена каждая из потоковых функций.

// Программа 4.2

void *task1(void *X)

{

int *Temp;

Temp = static_cast<int *>(X);

for(int Count = 1;Count < *Temp;Count++){

cout << «work from thread A: " << Count << " * 2 = "

<< Count * 2 << endl;

}

cout << «Thread A complete» << endl;

}

void *task2(void *X)

{

int *Temp;

Temp = static_cast<int *>(X);

for(int Count = 1;Count < *Temp;Count++){

cout << «work from thread B: " << Count << " + 2 = "

<< Count + 2 << endl;

}

cout << «Thread B complete» << endl;

}

В программе 4.2 функции taskl и task2 выполняют цикл, количество итераций которого равно числу, переданному каждой функции в качестве параметра. Одна функция увеличивает переменную цикла на два, вторая — умножает ее на два, а затем каждая из них отправляет результат в стандартный поток вывода данных. По выходу из цикла каждая функция выводит сообщение о завершении выполнения потока. Инструкции по компиляции и выполнению программ 4.1 и 4.2 содержатся в профиле программы 4.1.

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

Имя программы •program4-12.cc

* Описание Принимает целочисленное значение из командной строки и передает функциям: потоков. Каждая функция выполняет цикл, в котором переменная цикла увеличивается (в одной функции на два, а в другой в два раза), а затем результат отсылается в стандартный поток вывода данных. Код основного потока выполнения приведен в программе 4.1, а код функций — в программе 4.2.

Требуемая библиотека libpthread

Требуемые заголовки <pthread.h> <iostream> <stdlib.h>

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

с++ -о program4-12 program4-12.cc -lpthread

Среда для тестирования SuSE Linux 7.1, gcc 2.95.2,

Инструкции по выполнению ./program4-12 34

Примечания Эта программа требует задания аргумента командной строки.

В этом разделе был приведен пример передачи функции потока лишь одного аргумента. Если необходимо передать функции потока несколько аргументов, создайте структуру (struct) или контейнер, содержащий все требуемые аргументы, и передайте функции потока указатель на эту структуру.

Получение идентификатора потока

Как упоминалось выше, процесс разделяет все свои ресурсы с потоками, используя лишь собственное адресное пространство. Потокам в собственное пользование выделяются весьма небольшие их объемы. Идентификатор потока (id) — это один из ресурсов, уникальных для каждого потока. Чтобы узнать свой идентификатор, потоку необходимо вызвать функцию pthread_self ().

Синопсис

#include <pthread.h>

pthread_t pthread_self(void)

Эта функция аналогична функции getpid () для процессов. При создании потока его идентификатор возвращается его создателю или вызывающему потоку. Однако идентификатор потока не становится известным созданному потоку автоматически. Но если уж поток обладает собственным идентификатором, он может передать его (предварительно узнав его сам) другим потокам процесса. Функция pthread_self () возвращает идентификатор потока, не определяя никаких кодов ошибок.

Вот пример вызова этой функции:

pthread_t ThreadId;

ThreadId = pthread_self();

Поток вызывает функцию pthread_self(), а значение, возвращаемое ею (идентификатор потока), сохраняет в переменной ThreadId типа pthread_t.

Присоединение потоков

Функция pthread_join () используется для присоединения или воссоединения потоков выполнения в одном процессе. Эта функция обеспечивает приостановку выполнения вызывающего потока до тех пор, пока не завершится заданный поток. По своему Действию эта функция аналогична функции wait (), используемой процессами. Эту функцию может вызвать создатель потока, после чего он будет ожидать до тех пор, пока не завершится новый (созданный им) поток, что, образно говоря, можно назвать воссоединением потоков выполнения. Функцию pthread_join() могут также вызывать равноправные потоки, если потоковый дескриптор является глобальным. Это позволяет любому потоку соединиться с любым другим потоком выполнения в процессе. Если вызы вающий поток аннулируется до завершения заданного (для присоединения) потока,этот заданный поток не станет открепленным (detached) потоком (см. следующий раздел) Если различные равноправные потоки одновременно вызовут функцию pthread_join() для одного и того же потока, его дальнейшее поведение не определено.

Синопсис

#include <pthread.h>

int pthread_join(pthread_t thread, void **value_ptr);

Параметр thread представляет поток, завершения которого ожидает вызывающий поток. При успешном выполнении этой функции в параметре value_ptr будет записан статус завершения потока. Статус завершения — это аргумент, передаваемый при вызове функции pthread_exit () завершаемым потоком. При неудачном выполнении эта функция возвратит код ошибки. Функция не будет выполнена успешно, если заданный поток не является присоединяемым, т.е. создан как открепленный. Об успешном выполнении этой функции не может быть и речи, если заданный поток попросту не существует.

Функцию pthread_join () необходимо вызывать для всех присоединяемых потоков. После присоединения потока операционная система сможет снова использовать память, которую он занимал. Если присоединяемый поток не был присоединен ни к одному потоку или если поток, который вызывает функцию присоединения, аннулируется, то заданный поток будет продолжать использовать свою память. Это состояние аналогично зомбированному процессу, в которое переходит сыновний процесс, когда его родитель не принимает статус завершения потомка, и этот «беспризорный» сыновний процесс продолжает занимать структуру в таблице процессов.

Создание открепленных потоков

Открепленным называется завершаемый поток, который не присоединился или завершения которого не дождался другой поток. При завершении потока ограниченные ресурсы, которые он использовал, включая его идентификатор, освобождаются и возвращаются системе. Потокам нет необходимости получать статус завершения. Попытка со стороны любого потока вызвать функцию pthread_join () для открепленного потока обречена на неудачу. Существует функция pthread_detach (), которая открепляет поток, заданный параметром thread . По умолчанию все потоки создаются как присоединяемые, если атрибутным объектом не обусловлено иное. Эта функция позволяет открепить уже существующие присоединяемые потоки. Если поток не завершен, обращение к этой функции не обеспечит его завершения.

Синопсис

#include <pthread.h>

int pthread_detach(pthread_t thread thread);

При успешном выполнении эта функция возвращает число 0 , в противном случае— код ошибки. Функция pthread_detach() не будет успешной, если заданный поток уже откреплен или поток, заданный параметром thread, не был обнаружен.

Вот пример открепления уже существующего присоединяемого потока:

pthread_create(&threadA,NULL,taskl,NULL);

pthread_detach(threadA);

При выполнении этих строк кода поток threadA станет открепленным. Чтобы создать открепленный поток (в противоположность динамическому откреплению потока) необходимо установить атрибут detachstate в объекте атрибутов потока и использовать этот объект при создании потока.

Использование объекта атрибутов

Объект атрибутов инкапсулирует атрибуты потока или группы потоков. Он используется для установки атрибутов потоков при их создании. Атрибутный объект потока имеет тип pthread_attr_t. Он представляет собой структуру, позволяющую хранить следующие атрибуты:

• размер стека потока;

• местоположение стека потока;

• стратегия планирования, наследование и параметры;

• тип потока: открепленный или присоединяемый;

• область конкуренции потока.

Для типа pthread_attr_t предусмотрен ряд методов, которые могут быть вызваны для установки или считывания каждого из перечисленных выше атрибутов (см. табл. 4.3).

Для инициализации и разрушения атрибутного объекта потока используются функции pthread_attr_init () и pthread_attr_destroy () соответственно.

Синопсис

#include <pthread.h>

int pthread_attr_init(pthread_attr_t *attr);

int pthread_attr_destroy(pthread attr__t *attr) ;

Функция pthread_attr_init () инициализирует атрибутный объект потока с помощью стандартных значений, действующих для всех этих атрибутов. Параметр attr представляет собой указатель на объект типа pthread_attr_t. После инициализации attr-объекта значения его атрибутов можно изменить с помощью функций, перечисленных в табл. 4.3. После соответствующей модификации атрибутов значение attr используется в качестве параметра при вызове функции создания потока pthread_create(). При успешном выполнении эта функция возвращает число 0, в противном случае — код ошибки. Функция pthread_attr_init() завершится неуспешно, если для создания объекта в системе недостаточно памяти.

Функцию pthread_attr_destroy() можно использовать для разрушения объекта типа pthread_attr_t, заданного параметром attr. При обращении к этой функ ц ии будут удалены любые скрытые данные, связанные с этим атрибутным объектом потока. При успешном выполнении эта функция возвращает число 0, в противном случае - код ошибки.

Создание открепленных потоков с помощью объекта атрибутов

После инициализации объекта потока его атрибуты можно модифицировать. Дл я установки атрибута detachstate атрибутного объекта используется функция pthread__attr_setdetachstate(). Параметр detachstate описывает поток как открепленный или присоединяемый.

Синопсис

#include <pthread.h>

int pthread_attr_setdetachstate(

pthread_attr_t *attr,

int *detachstate

);

int pthread_attr_getdetachstate(

const pthread_attr_t *attr,

int *detachstate

);

Параметр detachstate может принимать одно из следующих значений:

PTHREAD_CREATE_DETACHED

PTHREAD_CREATE_JOINABLE

Значение PTHREAD_CREATE_DETACHED « превращает» все потоки, которые используют этот атрибутный объект, в открепленные, а значение PTHREAD_CREATE_JОINABLE — в присоединяемые. Значение PTHREAD_CREATE_JOINABLE атрибут detachstate принимает по умолчанию. При успешном выполнении функция pthread_attr_setdetachstate () возвращает число 0 , в противном случае — код ошибки. Эта функция выполнится неуспешно, если значение параметра detachstate окажется недействительным.

Функция pthread_attr_getdetachstate () возвращает значение атрибута detachstate атрибутного объекта потока. При успешном выполнении эта функция возвращает значение атрибута detachstate в параметре detachstate и число 0 обычным способом. При неудаче функция возвращает код ошибки. В листинге 4.2 показано, как открепляются потоки, созданные в программе4.1. В этом примере при создании одного из потоков используется объект атрибутов.

// Листинг 4.2. Использование атрибутного объекта для // создания открепленного потока

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

pthread_t ThreadA,ThreadB;

pthread_attr_t DetachedAttr;

int N;

if(argc != 2) {

cout « «Ошибка» << endl; exit (1);

}

N = atoi(argv[1]);

pthread_attr_init(&DetachedAttr);

pthread_attr_setdetachstate(&DetachedAttr,PTHREAD_CREATE_DETACHED);

pthread_create(&ThreadA,NULL, task1, &N);

pthread_create(&ThreadB,&DetachedAttr,task2 , &N);

cout << «Ожидание присоединения потока А.» << endl; pthread_join(ThreadA,NULL);

return (0) ;

}

В листинге 4.2 объявляется атрибутный объект DetachedAttr, для инициализации которого используется функция pthread_attr_init(). После инициализации этого объекта вызывается функция pthread_attr_detachstate(), которая изменяет свойство detachstate («присоединяемость»), установив значение PTHREAD_CREATE_DETACHED («открепленность»). При создании потока ThreadB с помощью функции pthread_create() в качестве ее второго аргумента используется модифицированный объект DetachedAttr. Для потока ThreadB вызов функции pthread_join() не используется, поскольку открепленные потоки присоединить невозможно.

Управление потоками

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

Завершение потоков

Выполнение потока может быть прервано по разным причинам:

• в результате выхода из процесса с возвращаемым им статусом завершения (или без него);

• в результате собственного завершения и предоставления статуса завершения;

• в результате аннулирования другим потоком в том же адресном пространстве.

Завершаясь, функция присоединения потока pthread_join() возвращает вызывающему потоку статус завершения, передаваемый функции pthread_exit(), которая была вызвана завершающимся потоком. Если завершающийся поток не обращался к функции pthread_exit (), то в качестве статуса завершения будет использовано значение, возвращаемое этой функцией, если оно существует; в противном случае статус завершения равен значению NULL. [9] Воз можна ситуация, когда одному потоку необходимо завершить другой поток в том же процессе. Например, приложение может иметь поток, который контролирует работу других потоков. Если окажется, что некоторый поток «плохо себя ведет», или больше не нужен, то ради экономии системных ресурсов, возможно, его нужно завершить. Завершающийся поток может окончиться немедленно или отложить завершение до тех пор, пока не достигнет в своем выполнении некоторой логической точки. При этом вполне вероятно, что такой поток (прежде чем завершиться) должен выполнить некоторые действия очистительно-восстановительного характера. Поток имеет также возможность отказаться от завершения.

Для завершения вызывающего потока используется функция pthread_exit () Значение value_ptr передается потоку, который вызывает функцию pthread_join() для этого потока. Еще не выполненные процедуры, связанные с «уборкой», будут выполнены вместе с деструкторами, предусмотренными для потоковых данных. Никакие ресурсы, используемые потоками, при этом не освобождаются.

Синопсис

#include <pthread.h>

int pthread_exit(void *value_ptr);

При завершении последнего потока в процессе завершается сам процесс со статусом завершения, равным 0. Эта функция не может вернуться к вызывающему потоку и не определяет никаких кодов ошибок.

Для отмены выполнения некоторого потока по инициативе потока из того же адресного пространства используется функция pthread__cancel (). Отменяемый поток задается параметром thread.

Синопсис

#include <pthread.h>

int pthread_cancel(pthread_t thread);

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

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

Состояние готовности к аннулированию (cancelability state) описывает условия, при которых поток может (или не может) быть аннулирован. Тип аннулирования (cancelabilty type) потока определяет способность потока продолжать выполнение после получения запросов на аннулирование. Поток может отреагировать на аннулирующий запрос немедленно или отложить аннулирование до определенной (более поздней) точки в его выполнении. Состояние готовности к аннулированию и тип аннулирования устанавливаются динамически самим потоком.

Для определения состояния готовности к аннулированию и типа аннулирования вызывающего потока используются функции p thread_setcancelstate() pthread_setcanceltype(). Функция pthread_setcancelstate() устанавливает вызывающий поток в состояние, заданное параметром state, и возвращает предыдущее состояние в параметре oldstate.

Синопсис

#include <pthread.h>

int pthread_setcancelstate(int state, int *oldstate);

int pthread_setcanceltype(int type, int *oldtype);

Параметры state и oldstate могут принимать такие значения:

PTHREAD_CANCEL_DISABLE

PTHREAD_CANCEL_ENABLE

Значение PTHREAD_CANCEL_DISABLE определяет состояние, в котором поток будет игнорировать запрос на аннулирование, а значение PTHREAD_CANCEL_ENABLE - состояние, в котором поток «согласится» выполнить соответствующий запрос (это состояние по умолчанию устанавливается для каждого нового потока). При успешном выполнении функция возвращает число 0 , в противном случае — код ошибки. Функция pthread_setcancelstate() не может выполниться успешно, если переданное

значение параметра state окажется недействительным. Функция pthread_setcanceltype () устанавливает для вызывающего потока тип аннулирования, заданный параметром type, и возвращает предыдущее значение типа в параметре oldtype. Параметры type и oldtype могут принимать такие значения:

PTHREAD_CANCEL_DEFFERED

PTHREAD_ASYNCHRONOUS

Значение PTHREAD_CANCEL_DEFFERED определяет тип аннулирования, при котором поток откладывает завершение до тех пор, пока он не достигнет точки, в котором его аннулирование возможно (этот тип по умолчанию устанавливается для каждого нового потока). Значение PTHREAD_CANCEL_ASYNCHRONOUS определяет тип аннулирования, при котором поток завершается немедленно. При успешном выполнении функция возвращает число 0 , в противном случае— код ошибки. Функция pthread_setcanceltype() не может выполниться успешно, если переданное ей значение параметра type окажется недействительным.

Функции pthread_setcancelstate() и pthread_setcanceltype() используются вместе для установки отношения вызывающего потока к потенциальному запросу на аннулирование. Возможные комбинации значений состояния и типа аннулирования перечислены и описаны в табл. 4 .5.

Таблица 4.5. Комбинации значений состояния и типа аннулирования

Состояние   Тип   Описание

PTHREAD_CANCEL_ENABLE (PTHREAD_CANCEL_DEFERRED) Отсроченное аннулирование. Эти состояние и тип аннулирования потока устанавливаются по умолчанию. Аннулирование потока происходит, когда он достигает соответствующей точки в своем выполнении или когда программист определяет точку аннулирования с помощью функции pthread_testcancel()

PTHREAD_CANCEL_ENABLE (PTHREAD_CANCEL_ASYNCHRONOUS)

Асинхронное аннулирование. Аннулирование потока происходит немедленно

PTHREAD_CANCEL_DISABLE (любое)

Аннулирование запрещено. Оно вообще не выполняется

Точки аннулирования потоков

Если удовлетворение запроса на аннулирование потока откладывается, значит, оно произойдет позже, когда это делать «безопасно», т.е. когда оно не попадает на период выполнения некоторого критического кода, блокирования мьютекса или пребывания данных в некотором «промежуточном» состоянии. Вне этих «опасных» разделов кода потоков вполне можно устанавливать точки аннулирования. Точка аннулирования — это контрольная точка, в которой поток проверяет факт существования каких-либо ждущих (отложенных) запросов на аннулирование и, если таковые имеются, разрешает завершение.

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

Синопсис

#include <pthread.h>

void pthread_testcancel(void)

Программа 4.3 содержит функции, которые вызывают функции pthread_setcancelstate(), pthread_setcanceltype() и pthread_testcancel(), связанные с установкой типа аннулирования потока и состояния готовности к аннулированию.

#include <iostream>

#include <pthread.h>

void *task1(void *X)

{

int OldState;

// disable cancelability

pthread_setcancelstate(PTHREAD_CANCEL_DISABLE,&OldState);

for(int Count = 1;Count < 100;Count++)

{

cout << «thread A is working: " << Count << endl;

}

}

void *task2(void *X)

{

int OldState,OldType;

// enable cancelability, asynchronous

pthread_setcancelstate(PTHREAD_CANCEL_ENABLE,&OldState);

pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS,&OldType);

for(int Count = 1;Count < 100;Count++)

{

cout << «thread B is working: " << Count << endl;

}

}

void *task3(void *X)

{

int OldState,OldType;

// enable cancelability, deferred

pthread_setcancelstate(PTHREAD_CANCEL_ENABLE,&OldState);

pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED,&OldType);

for(int Count = 1;Count < 1000;Count++)

{

cout << «thread C is working: " << Count << endl;

if((Count%100) == 0){

pthread_testcancel();

}

}

}

В программе 4.3 каждая задача устанавливает свое условие аннулирования. В задаче task1 аннулирование потока запрещено, поскольку вся она состоит из критического кода, который должен быть выполнен до конца. В задаче task2 аннулирование потока разрешено. Обращение к функции pthread_setcancelstate () является необязательным, поскольку все новые потоки имеют статус разрешения аннулирования. Тип аннулирования здесь устанавливается равным значению PTHREAD_CANCEL_ASYNCHRONOUS Это означает, что после поступления запроса на аннулирование поток немедленно запустит соответствующую процедуру, независимо от того, на какой этап его выполнения придется этот запрос. А поскольку этот поток установил для себя именно такой тип аннулирования, значит, он не выполняет никакого «жизненно важного» кода. Например, вызовы системных функций должны попадать под категорию опасных для аннулирования, но в задаче task2 таких нет. Там выполняется лишь цикл, который будет работать до тех пор, пока не поступит запрос на аннулирование. В задаче task3 аннулирование потока также разрешено, а тип аннулирования устанавливается равным значению PTHREAD_CANCEL_DEFFERED. Эти состояние и тип аннулирования действуют по умолчанию для новых потоков, следовательно, обращения к функциям pthread_setcancelstate() и pthread_setcanceltype() здесь необязательны. Критический код этого потока здесь может спокойно выполняться после установки состояния и типа аннулирования, поскольку процедура завершения не стартует до вызова функции pthread_testcancel (). Если не будут обнаружены ждущие запросы, поток продолжит свое выполнение до тех пор, пока не встретит очередные обращения к функции pthread_testcancel() (если таковые предусмотрены). В задаче task3 функция pthread_cancel () вызывается только после того, как переменная Count без остатка разделится на число 100 . Код, расположенный между точками аннулирования потока, не должен быть критическим, поскольку он может не выполниться.

Программа 4.4 содержит управляющий поток, который делает запрос на аннулирование каждого рабочего потока.

// Программа 4.4

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

pthread_t Threads[3]; void *Status;

pthread_create(&(Threads[0]),NULL,taskl, NULL); pthread_create(&(Threads[l]), NULL,task2,NULL); pthread_create(&(Threads[2]),NULL,task3,NULL);

pthread_cancel(Threads[0]); pthread_cancel(Threads[l]); pthread_cancel(Threads[2]);

for(int Count = 0;Count < 3;Count++) {

pthread_join(Threads[Count],&Status); if(Status == PTHREAD_CANCELED){

cout << «Поток» << Count << " аннулирован.» << endl;

}

else{

cout « «Поток» << Count << " продолжает выполнение.» << endl;

}

}

return (0) ;

}

Управляющий поток в программе 4.4 сначала создает три рабочих потока, затем делает запрос на аннулирование каждого из них. Управляющий поток для каждого рабочего потока вызывает функцию pthread_join(). Эта функция завершается успешно даже тогда, когда она пытается присоединить поток, который уже завершен, функция присоединения в этом случае просто считывает статус завершения завершенного потока. И такое поведение весьма кстати, поскольку поток, который сделал запрос на аннулирование, и поток, вызвавший функцию pthread_join (), могут оказаться совсем разными потоками. Мониторинг функционирования всех рабочих потоков может оказаться единственной задачей того потока, который «по совместительству» и аннулирует потоки. Опрашивать же статус завершения потоков с помощью функции pthread_join() может совершенно другой поток. Этот тип информации используется для получения статистической оценки того, какой из потоков наиболее эффективен. В рассматриваемой нами программе все это делает один управляющий поток: в цикле он и присоединяет рабочие потоки, и проверяет их статус завершения. Поток Threads[0] не аннулирован, поскольку он имеет запрет на аннулирование, в то время как два остальных потока были аннулированы. Статус завершения аннулируемого потока может иметь, например, значение PTHREAD_CANCELED. Профили программ 4.3 и 4.4 представлены в разделе «Профиль программы 4.2».

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

Имя программы program4-34. cc ;

Описание Демонстрирует аннулирование потоков. Три потока имеют различные типы состояния аннулирования. Каждый поток выполняет цикл. Состояние и тип аннулирования определяет количество итераций цикла и то, будет ли цикл выполняться вообще. Основной поток определяет статус завершения каждого , рабочего потока.

Требуемая библиотека libpthread

Тр ебуемые заголовки <pthread.h> <iostream>

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

с++ -о program4-34 program4-34.сс -lpthread

Среда для тестирования SuSE Linux 7.1, gcc 2.95.2.

И нс трукции по выполнению ./program4-34

В функциях, определенных пользователем, используются точки аннулирования отмеченные обращением к функции pthread_testcancel(). Библиотека Pthread определяет в качестве точек аннулирования выполнение других функций. Эти функции блокируют вызывающий поток, а заблокированному потоку аннулирование не грозит. Вот эти функции библиотеки Pthread:

pthread_testcancel()

pthread_cond_wait()

pthread_timedwait()

pthread_join()

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

Таблица 4.6. Системные POSIX-функции, претендующие на роль точек аннулирования

accept()

nanosleep()

sem_wait()

aio_suspend()

open()

send()

clock_nanosleep()

pause()

sendmsg()

close()

poll()

sendto()

connect()

pread()

sigpause()

creat()

pthread_cond_timedwait()

sigsuspend()

fcntl()

pthread_cond_wait()

sigtimedwait()

fsync()

pthread_join()

sigwait()

getmsg()

putmsg()

sigwaitinfo()

lockf()

putpmsg()

sleep()

mq_receive()

pwrite()

system()

mq_send()

read()

usleep()

mq_timedreceive()

readv()

wait()

mq_timedsend ()

recvfrom()

waitpid()

msgrcv()

recvmsg()

write()

msgsnd()

select()

writev()

msync()

sem_timedwait()

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

Очистка перед завершением

Поток, «позволивший» себя аннулировать, прежде чем завершиться, обычно должен выполнить некоторые заключительные действия. Так, нужно закрыть файлы, привести разделяемые данные в надлежащее состояние, снять блокировки или освободить занимаемые ресурсы. Библиотека Pthread определяет механизм поведения каждого потока «в последние минуты своей жизни». С каждым потоком связывается стек очистительно-восстановительных операций (cleanup stack), который содержит указатели на процедуры (или функции), предназначенные для выполнения во время аннулирования потока. Для того чтобы поместить в этот стек указатель на процедуру, предусмотрена функция pthread_cleanup_push ().

Синопсис

#include <pthread.h>

void pthread_cleanup_push(void (*routine)(void *),void *arg);

void pthread cleanup pop(int execute);

Параметр routine представляет собой указатель на функцию, помещаемый в стек завершающих процедур. Параметр arg содержит аргумент, передаваемый этой routine -функции, которая вызывается при завершении потока с помощью функции pthread_exit (), когда поток «покоряется» запросу на аннулирование или явным образом вызывает функцию pthread__cleanup_pop () с ненулевым значением параметра execute. Функция, заданная параметром routine, не возвращает никакого значения.

Функция pthread_cleanup_pop() удаляет указатель routine -функции из вершины стека завершающих процедур вызывающего потока. Параметр execute может принимать значение 1 или 0. Если его значение равно 1, поток выполняет routine- функцию, даже если он при этом и не завершается. Поток продолжает свое выполнение с инструкции, расположенной за вызовом функции pthread_cleanup_pop(). Если значение параметра execute равно 0, указатель извлекается из вершины стека потока без выполнения routine -функции.

Необходимо позаботиться о том, чтобы для каждой функции занесения в стек (push) существовала функция извлечения из стека (pop) в пределах одной и той же лексической области видимости. Например, для функции funcA () обязательно выполнение cleanup -обработчика при ее нормальном завершении или аннулировании:

void *funcA(void *X)

{

int *Tid;

Tid = new int;

// do some work

//...

pthread_cleanup_push(cleanup_funcA,Tid);

// do some more work

//...

pthread_cleanup_pop(0);

}

Здесь функция funcA( ) помещает указатель на обработчик cleanup_funcA( ) в стек завершающих процедур путем вызова функции pthread_cleanup_push (). Каждому обращению к этой функции должно соответствовать обращение к функции pthread_cleanup_pop(). Если функции извлечения указателя из стека (pop- функции) передается значение 0, то извлечение из стека состоится, но без выполнения обработчика. Обработчик будет выполнен лишь при аннулировании потока, выполняющего функцию funcA().

Для функции funcB () также требуется cleanup -обработчик:

void *funcB(void *X)

{

int *Tid;

Tid = new int;

// do some work

//...

pthread_cleanup_push(cleanup_funcB,Tid);

// do some more work

//...

pthread_cleanup_pop(1);

}

Здесь функция funcB () помещает указатель на обработчик cleanup_funcB () в стек завершающих процедур. Отличие этого примера от предыдущего состоит в том, что функции pthread_cleanup_pop () передается параметр со значением 1, т.е. после извлечения из стека указателя на обработчик этот обработчик будет тут же выполнен. Необходимо отметить, что выполнение обработчика в данном случае состоится «при любой погоде», т.е. и при аннулировании потока, который обеспечивает выполнение функции funcB( ), и при обычном его завершении. Обработчики- «уборщики», cleanup_funcA() и cleanup_funcB (), — это обычные функции, которые можно использовать для закрытия файлов, освобождения ресурсов, разблокирования мьютексов и пр.

Управление стеком потока

Адресное пространство процесса делится на раздел кода, раздел статических данных, свободную память и раздел стеков. Стекам потоков выделяется область из стекового раздела процесса. Стек потока предназначен для хранения стекового фрейма, связанного с каждой процедурой (функцией), которая была вызвана, но еще не завершена. Стековый фрейм содержит временные переменные, локальные переменные, адреса точек возврата и любую другую дополнительную информацию, которая необходима потоку, чтобы найти «обратную дорогу» к ранее вызванным процедурам. При выходе из процедуры (функции) ее стековый фрейм извлекается из стека. Расположение фреймов в стеке схематично показано на рис. 4.12.

Предположим, что поток А (см. рис. 4.12) выполняет функцию task1 () , которая создает некоторые локальные переменные, выполняет заданную обработку, а затем вызывает функцию taskX (). При этом для функции task1 () создается стековый фрейм, который помещается в стек потока. Функция taskX () выполняет «свои» действия, создает локальные переменные, а затем вызывает функцию taskC (). Нетрудно догадаться, что стековый фрейм, созданный для функции taskX () , также помещается в стек. Функция taskC () вызывает функцию taskY() и т.д. Каждый стек должен иметь достаточно большой размер, чтобы поместить всю информацию, необходимую для выполнения всех функций потока, а также цепочки других подпрограмм, которые будут вызваны потоковыми функциями. Размером и местоположением стека потока управляет операционная система, но для установки и считывания этой информации предусмотрены методы, которые определены в объекте атрибутов потока.

Рис. 4.12. Стековые фреймы, сгенерированные потоками

Функция pthread_attr_getstacksize( ) возвращает минимальный размер стека, устанавливаемый по умолчанию. Параметр attr определяет объект атрибутов потока, из которого считывается стандартный размер стека. При успешном выполнении функция возвращает значение 0, а стандартный размер стека, выраженный в байтах, coxpaняется в параметре stacksize. В случае неудачи функция возвращает код ошибки.

Функция pthread_attr_setstacksize() устанавливает минимальный размер стека. Параметр attr определяет объект атрибутов потока, для которого устанавливается размер стека. Параметр stacksize содержит минимальный размер стека, выраженный в байтах. При успешном выполнении функция возвращает значение 0 , в противном случае - код ошибки. Функция завершается неудачно, если значение параметра stacksize оказывается меньше значения PTHREAD_MIN_STACK или превышает системный минимум. Вероятно, значение PTHREAD_STACK_MIN будет меньше минимального размера стека, возвращаемого функцией p thread_attr_getstacksize(). Прежде чем увеличивать минимальный размер стека потока, следует поинтересоваться значением, возвращаемым функцией p thread_attr_getstacksize() р азмер ст ека фиксируется, чтобы его расширение во время выполнения программы ограничивалось рамками фиксированного пространства стека, установленного во время компиляции.

Синопсис

#include <pthread.h>

void pthread_attr_getstacksize(

const pthread_attr_t *restrict attr, void **restrict stacksize);

void pthread_attr_setstacksize(pthread_attr_t *attr, void *stacksize);

Местоположение стека потока можно установить и прочитать с помощью функций pthread_attr_setstackaddr() и pthread_attr_getstackaddr(). Функция pthread_attr_setstackaddr() для потока, создаваемого с помощью атрибутного объекта, заданного параметром attr, устанавливает базовый адрес стека равным адресу, заданному параметром stackaddr. Этот адрес stackaddr должен находиться в пределах виртуального адресного пространства процесса. Размер стека должен быть не меньше минимального размера стека, задаваемого значением PTHREAD_STACK_MIN. При успешном выполнении функция возвращает значение 0 , в противном случае — код ошибки.

Функция pthread_attr_getstackaddr () считывает базовый адрес стека для потока, создаваемого с помощью атрибутного объекта потока, заданного параметром attr. Считанный адрес сохраняется в параметре stackaddr. При успешном выполнении функция возвращает значение 0 , в противном случае — код ошибки.

Синопсис

#include <pthread.h>

void pthread_attr_setstackaddr(pthread_attr_t *attr,

void *stackaddr);

void pthread_attr_getstackaddr(const pthread_attr_t *restrict attr, void **restrict stackaddr);

Атрибуты стека (размер и местоположение) можно установить с помощью одной функции. Функция pthread_attr_setstack() устанавливает как размер, так и адрес стека для потока, создаваемого с помощью атрибутного объекта, заданного параметром attr. Базовый адрес стека устанавливается равным адресу, заданному параметром stackaddr, а размер стека — равным значению параметра stacksize. Функция pthread_attr_getstack() считывает размер и адрес стека для потока, создаваемого с помощью атрибутного объекта, заданного параметром attr. При успешном выполнении функция возвращает значение 0 , в противном случае — код ошибки. Если считывание атрибутов стека прошло успешно, адрес будет записан в параметр stackaddr, а размер— в параметр stacksize. Функция pthread_setstack() выполнится неудачно, если значение параметра stacksize окажется меньше значения PTHREAD_STACK_MIN или превысит некоторый предел, определяемый реализацией.

Синопсис

#include <pthread.h>

void pthread_attr_setstack(pthread_attr_t *attr, void *stackaddr,

size_t stacksize);

void pthread_attr_getstack(const pthread_attr_t *restrict attr,

void **restrict stackaddr, size_t stacksize);

В листинге 4.3 показан пример установки размера стека для потока, создаваемого с помощью атрибутного объекта.

// Листинг 4.3. Изменение размера стека для потока

//  с использованием смещения

pthread_attr_getstacksize(&SchedAttr, &DefaultSize) ;

if(DefaultSize < Min_Stack_Req){

SizeOffset = Min_Stack_Req - DefaultSize;

NewSize = DefaultSize + SizeOffset;

pthread_attr_setstacksize(&Attrl, (size_t)NewSize);

}

В листинге 4.3 сначала из атрибутного объекта потока считывается размер стека, действующий по умолчанию. Затем, если окажется, что этот размер меньше желаемого минимального размера стека, вычисляется разность между сравниваемыми размерами, после чего значение этой разности (смещение) суммируется с размером стека, используемым по умолчанию. Результат суммирования становится новым минимальным размером стека для этого потока.

ПРИМЕЧАНИЕ: установка размера и местоположения стека может сделать вашу программу непереносимой. Размер и местоположение стека, устанавливаемые на одной платформе, могут оказаться неподходящими для использования в качестве размера и местоположения стека для другой платформы.

Установка атрибутов планирования и свойств потоков

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

pthread_attr_setinheritsched()

pthread_attr_setschedpolicy()

pthread_attr_setschedparam()

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

pthread_attr_getinheritsched()

pthread_attr_getschedpolicy()

pthread_attr_getschedparam()

Синопсис

#include <pthread.h>

#include <sched.h>

void pthread_attr_setinheritsched(pthread_attr_t *attr, int inheritsched);

void pthread_attr_setschedpolicy(pthread_attr_t *attr, int policy);

void pthread_attr_setschedparam(pthread_attr_t *restrict attr,

const struct sched_param *restrict param);

Функции pthread_attr_setinheritsched(), pthread_attr_setschedpolicy () и pthread_attr_setschedparam() используются для установки стратегии планирования и приоритета потока. Функция pthread_attr_setinheritsched() позволяет определить, как будут устанавливаться атрибуты планирования потока: путем наследования от потока-создателя или в соответствии с содержимым объекта атрибутов. Параметр inheritsched может принимать одно из следующих значений.

PTHREAD_INHERIT_SCHED Атрибуты планирования потока должны быть унаследованы от потока-создателя, при этом любые атрибуты планирования, определяемые параметром attr, будут игнорироваться.

PTHREAD_EXPLICIT_SCHED Атрибуты планирования потока должны быть установлены в соответствии с атрибутами планирования, хранимыми в объекте, заданном параметром attr.

Если параметр inheritsched получает значение PTHREAD_EXPLICIT_SCHED, то функция pthread_attr_setschedpolicy() используется для установки стратегии планирования, а функция pthread_attr_setschedparam() — установки приоритета.

Функция pthread_attr_setschedpolicy() устанавливает член объекта атрибутов потока (заданного параметром attr), «отвечающий» за стратегию планирования потока. Параметр policy может принимать одно из следующих значений, определенных в заголовке <sched. h>.

SCHED_FIFO Стратегия планирования типа FIFO (первым прибыл, первым обслужен), при которой поток выполняется до конца.

SCHED_RR  Стратегия циклического планирования, при которой каждый поток

назначается процессору только в течение некоторого кванта времени- SCHED_OTHER Стратегия планирования другого типа (определяемая реализацией)-Для любого нового потока эта стратегия планирования принимается по умолчанию.

Функ ция pthread_attr_setschedparam() используется для установки членов атрибутного объекта (заданного параметром attr), связанных со стратегией планирования Параметр param представляет собой структуру, которая содержит эти члены. Структура sched_param включает по крайней мере такой член данных: struct sched_param {

int sched_priority;

//...

};

Возможно, эта структура содержит и другие члены данных, а также ряд функций, предназначенных для установки и считывания минимального и максимального значений приоритета, атрибутов планировщика и пр. Но если для задания стратегии планирования используется либо значение SCHED_FIFO, либо значение SCHED_RR, то в структуре sched_param достаточно определить только член sched_priority.

Чтобы получить минимальное и максимальное значения приоритета, используйте функции sched_get_priority_min () и sched_get_priority_max ().

Синопсис

#include <sched.h>

int sched_get_priority_max(int policy);

int sched_get_priority_min(int policy);

Обеим функциям в качестве параметра policy передается значение, определяющее выбранную стратегию планирования, для которой нужно установить значения приоритета, и обе функции возвращают соответствующее значение приоритета (минимальное и максимальное) для заданной стратегии планирования.

Как установить стратегию планирования и приоритет потока с помощью атрибутного объекта, показано в листинге 4.4.

// Листинг 4.4. Использование атрибутного объекта потока И   для установки стратегии планирования и

II   приоритета потока

#define Min_Stack_Req 3000000

pthread_t ThreadA;

pthread_attr_t SchedAttr;

size_t DefaultSize,SizeOffset,NewSize;

int MinPriority,MaxPriority,MidPriority;

sched_param SchedParam;

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

{

//...

// initialize attribute object

pthread_attr_init(&SchedAttr);

// retrieve min and max priority values for scheduling policy

MinPriority = sched_get_priority_max(SCHED_RR);

MaxPriority = sched_get_priority_min(SCHED_RR);

// calculate priority value

MidPriority = (MaxPriority + MinPriority)/2;

// assign priority value to sched_param structure

SchedParam.sched_priority = MidPriority;

// set attribute object with scheduling parameter

pthread_attr_setschedparam(&Attr1,&SchedParam);

// set scheduling attributes to be determined by attribute object

pthread_attr_setinheritsched(&Attr1,PTHREAD_EXPLICIT_SCHED);

// set scheduling policy

pthread_attr_setschedpolicy(&Attr1,SCHED_RR);

// create thread with scheduling attribute object

pthread_create(&ThreadA,&Attr1,task2,Value);

}

В листинге 4.4 стратегия планирования и приоритет потока ThreadA устанавливаются с использованием атрибутного объекта SchedAttr. Выполним следующие действия.

1. Инициализируем атрибутный объект.

2. Считаем минимальное и максимальное значения приоритета для стратегии планирования.

3. Вычислим значение приоритета.

4. Запишем значение приоритета в структуру sched_param.

5.  Установим атрибутный объект.

6. Обеспечим установку атрибутов планирования с помощью атрибутного объекта.

7. Установим стратегию планирования.

8. Создадим поток с помощью атрибутного объекта.

Последовательное выполнение этих действий позволяет установить стратегию планирования и приоритет потока до его создания. Для динамического изменения стратегии планирования и приоритета используйте функции pthread_setschedparam () и pthread_setschedprio().

Синопсис

#include <pthread.h>

int pthread_setschedparam(pthread_t thread,

int policy,

const struct sched_param *param);

int pthread_getschedparam(

pthread_t thread,

int *restrict policy,

struct sched_param *restrict param);

int pthread_setschedprio(pthread_t thread, int prio);

Функция pthread_setschedparam() устанавливает как стратегию планирования, так и приоритет потока без использования атрибутного объекта. Параметр thread содержит идентификатор потока, параметр policy — новую стратегию планирования и параметр param — значения, связанные с приоритетом. Функция pthread_getschedparam() сохраняет значения стратегии планирования и приоритета в параметрах policy и param соответственно. При успешном выполнении обе функции возвращают число 0 , в противном случае — код ошибки. Условия, при которых эти функции могут завершиться неудачно, перечислены в табл. 4.7.

Таблица4.7. Условия потенциального неудачного завершения функций установки стратегии планирования и приоритета

Функции

Условия отказа

pthread_getschedparam

• Параметр thread не ссылается на существующий поток

pthread_setschedparam

• Некорректен параметр policy или один из членов структуры, на которую указывает параметр param

• Параметр policy или один из членов структуры, на которую указывает параметр param, содержит значение, которое не поддерживается в данной среде

• Вызывающий поток не имеет соответствующего разрешения на установку значений приоритета или стратегии планирования для заданного потока

• Параметр thread не ссылается на существующий поток

• Данная реализация не позволяет приложению заменить один из параметров планирования заданным значением

pthread_setschedprio

• Параметр prio не подходит к стратегии планирования заданного потока

• Параметр prio имеет значение, которое не поддерживается в данной среде

• Вызывающий поток не имеет соответствующего разрешения на установку приоритета для заданного потока

• Параметр thread не ссылается на существующий поток

• Данная реализация не позволяет приложению заменить значение приоритета заданным

Функция pthread_setschedprio() используется для установки значения приоритета выполняемого потока, идентификатор которого задан параметром thread В результате выполнения этой функции текущее значение приоритета будет заменено значением параметра prio. При успешном выполнении функция возвращает число 0 в противном случае — код ошибки. При неуспешном выполнении функции приоритет потока изменен не будет. Условия, при которых эта функция может завершиться неуспешно, также перечислены в табл. 4.7.

ПРИМЕЧАНИЕ: к изменению стратегии планирования или приоритета выполняемого потока необходимо отнестись очень осторожно. Это может непредсказуемым образом повлиять на общую эффективность приложения. Потоки с более высоким приоритетом будут вытеснять потоки с более низким, что приведет к зависанию либо к тому, что поток будет постоянно выгружаться с процессора и поэтому не сможет завершить выполнение.

Установка области конкуренции потока

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

Синопсис

#include <pthread.h>

int pthread_attr_setscope(pthread_attr_t *attr,

int contentionscope);

int pthread_attr_getscope(

const pthread_attr_t *restrict_attr,

int *restrict contentionscope) ;

Функция pthread_attr_setscope() устанавливает член объекта атрибутов потока (заданного параметром attr), связанный с областью конкуренции. Область конкуренции потока будет установлена равной значению параметра contentionscope, который может принимать следующие значения.

PTHREAD_SCOPE_SYSTEM Область конкуренции системного уровня PTHREAD_SCOPE_PROCESS Область конкуренции уровня процесса

Функция pthread_attr_getscope() возвращает атрибут области конкуренции из объекта атрибутов потока, заданного параметром attr. При успешном выполнении значение области конкуренции сохраняется в параметре contentionscope. Обе функции при успешном выполнении возвращают число 0 , в противном случае — код ошибки-

Использование функции sysconf ()

Знание пределов, устанавливаемых системой на использование ресурсов, позволит вашему приложению эффективно управлять ресурсами. Например, максимальное количество потоков, приходящихся на один процесс, составляет верхнюю границу числа рабочих потоков, которое может быть создано процессом. Функция sysconf () используется для получения текущего значения конфигурируемых системных пределов или опций

Синопсис

#include <unistd.h>

#include <limits.h>

Параметр name - это запрашиваемая системная переменная. Функция возвращает значения, соответствующие стандарту POSIX IEEE Std. 1003.1-2001 для заданных системных переменных. Эти значения можно сравнить с константами, определенными вашей реализацией стандарта, чтобы узнать, насколько они согласуются между собой. Для ряда системных переменных существуют константы-аналоги, относящиеся к потокам, процессам и семафорам (см. табл. 4.8).

Если параметр name не действителен, функция sysconf () возвращает число -1 и устанавливает переменную errno, свидетельствующую об ошибке. Однако для заданного параметра name предел может быть не определен, и функция может возвращать число -1 как действительное значение. В этом случае переменная errno не устанавливается. Необходимо отметить, что неопределенный предел не означает безграничность ресурса Это просто означает, что не определен максимальный предел и (при условии доступности системных ресурсов) могут поддерживаться более высокие предельные значения. Рассмотрим пример вызова функции sysconf ():

if(PTHREAD_STACK_MIN == (sysconf(_SC_THREAD_STACK_MIN))){

//...

}

Значение константы PTHREAD_STACK_MIN сравнивается со значением, возвращаемым функцией sysconf (), вызванной с параметром _SC_THREAD_STACK_MIN.

Таблица4 .8. Системные переменные и соответствующие им символьные константы

Переменная

Значение

Описание

_SC_THREADS

_POSIX_THREADS

Поддерживает потоки

_SC_THREAD_ATTR_ STACKADDR

_POSIX_THREAD_ATTR_ STACKADDR

Поддерживает атрибут адреса стека потока

_SC_THREAD_ATTR_ STACKSIZE

_POSIX_THREAD_ATTR_ STACKSIZE

Поддерживает атрибут размера стека потока

_SC_THREAD_STACK_ MIN

PTHREAD_STACK_MIN

Минимальный размер стека потока в байтах

_SC_THREAD_THREADS_MAX

PTHREAD_THREADS MAX

Максимальное количество потоков на процесс

_SC_THREAD_KEYS_MAX

PTHREAD_KEYS_MAX

Максимальное количество ключей на процесс

_SC_THREAD_PRIO_INHERIT

_POSIX_THREAD_PRIO_ INHERIT

Поддерживает опцию наследования приоритета

_SC_THREAD_PRIO

_POSIX THREAD_PRIO

Поддерживает опцию приоритета потока

_SC_THREAD_PRIORITY_ SCHEDULING

_POSIX_THREAD_PRIORITY_SCHEDULING

Поддерживает опцию планирования приоритета потока

_SC_THREAD_PROCESS_SHARED

_POSIX_THREAD_PROCESS_SHARED

Поддерживает синхронизацию на уровне процесса

_SC_THREAD_SAFE_ FUNCTIONS

_POSIX_THREAD_SAFE_FUNCTIONS

Поддерживает функции безопасности потока

_SC_THREAD_ DESTRUCTOR_ ITERATIONS

_PTHREAD_THREAD_DESTRUCTOR_ITERATIONS

Определяет количество попыток, направленных на разрушение потоковых данных при завершении потока

_SC_CHILD_MAX

CHILD_MAX

Максимальное количество процессов, разрешенных для UID

_SC_PRIORITY_ SCHEDULING

_POSIX_PRIORITY_ SCHEDULING

Поддерживает планирование процессов

_SC_REALTIME_ SIGNALS

_POSIX_REALTIME_SIGNALS

Поддерживает сигналы реального времени

_SC_XOPEN_REALTIME_THREADS

_XOPEN_REALTIME_ THREADS

Поддерживает группу потоковых средств реального времени X/Open POSIX

_SC_STREAM_MAX

STREAM_MAX

Определяет количество потоков данных, которые один процесс может открыть одновременно

_SC_SEMAPHORES

_POSIX_SEMAPHORES

Поддерживает семафоры

_SC_SEM_NSEMS_MAX

SEM_NSEMS_MAX

Определяет максимальное количество семафоров, которое может иметь процесс

_SC_SEM_VALUE_MAX

SEM_VALUE_MAX

Определяет максимальное значение, которое может иметь семафор

_SC_SHARED_MEMORY_ OBJECTS

_POSIX_SHARED_MEMORY_OBJECTS

Поддерживает объекты общей памяти

Управление критическими разделами

Параллельно выполняемые процессы (или потоки в одном процессе) могут совместно использовать структуры данных, переменные или отдельные данные. Разделение глобальной памяти позволяет процессам или потокам взаимодействовать друг с другом и получать доступ к общим данным. При использовании нескольких процессов разделяемая глобальная память является внешней по отношению к ним. Внешнюю структуру данных можно использовать для передачи данных или команд между процессами. Если же необходимо организовать взаимодействие потоков, то они могут иметь доступ к структурам данных или переменным, являющимся частью одного и того же процесса, которому они принадлежат.

Если существуют процессы или потоки, которые получают доступ к разделяемым модифицируемым данным, структурам данных или переменным, то все эти данные находятся в критической области (или разделе) кода процессов или потоков. Критический раздел кода — это та его часть, в которой обеспечивается доступ потока или процесса к разделяемому блоку модифицируемой памяти и обработка соответствующих данных. Отнесение раздела кода к критическому можно использовать для управления состоянием «гонок». Например, создаваемые в программе два потока, поток А и поток В, используются для поиска нескольких ключевых слов во всех файлах системы. Поток А просматривает текстовые файлы в каждом каталоге и записывает нужные пути в списочную структуру данных TextFiles, а затем инкрементирует переменную FileCount. Поток В выделяет имена файлов из списка TextFiles, декрементирует переменную FileCount, после чего просматривает файл на предмет поиска в нем заданных ключевых слов. Файл, который их содержит, переписывается в другой файл, и инкрементируется еще одна переменная FoundCount. К переменной FoundCount поток А доступа не имеет. Потоки А и В могут выполняться одновременно на отдельных процессорах. Поток А выполняется до тех пор, пока не будут просмотрены все каталоги, в то время как поток В просматривает каждый файл, путь к которому выделен из переменной TextFiles. Упомянутый список поддерживается в отсортированном порядке, и в любой момент его содержимое можно отобразить на экране.

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

Если потоки или процессы одновременно лишь читают один и тот же блок памяти, условия «гонок» не возникают. Они возникают в случае, когда несколько процессов или потоков одновременно получают доступ к одному и тому же блоку памяти, и по крайней мере один из этих процессов или потоков делает попытку модифицировать данные. Раздел кода становится критическим, когда он делает возможными одновременные попытки изменить один и тот же блок памяти. Один из способов защитить к ритический раздел — разрешить только монопольный доступ к блоку памяти. Монопольный доступ означает, что к разделяемому блоку памяти будет иметь доступ один процесс или поток в течении короткого промежутка времени, при этом всем остальным процессам или потокам запрещено (путем блокировки) входить в свои критические разделы, которые обеспечивают доступ к тому же самому блоку памяти.

Для управления условиями «гонок» можно использовать такой механизм блокировки, как взаимо - исключающий семафор , или мьютекс (mutex— сокращение от «mutual exclusion», - взаимное исключение). Мьютекс используется для блокирования критического раздела: он блокируется до входа в критический раздел, а при выходе из него - деблокируется:

Блокирование мьютекса

// Вход в критический раздел.

// Доступ к разделяемой модифицируемой памяти.

// Выход из критического раздела.

Деблокирование мьютекса

Класс pthread_mutex_t позволяет смоделировать мьютексный объект. Прежде, чем объект типа pthread_mutex_t можно будет использовать, его необходимо инициализировать. Для инициализации мьютекса используется функция pthread_mutex_init(). Инициализированный мьютекс можно заблокировать деблокировать и разрушить с помощью функций pthread_mutex_lock(), pthread_mutex_unlock () и pthread_mutex_destroy () соответственно. В программе 4.5 содержится функция, которая выполняет поиск текстовых файлов, а в программе 4.6 — функция, которая просматривает каждый текстовый файл на предмет содержания в нем заданных ключевых слов. Каждая функция выполняется потоком. Основной поток реализован в программе 4.7. Эти программы реализуют модель «изготовитель-потребитель» для делегирования задач потокам. Программа4.5 содержит поток-«изготовитель», а программа 4.6 — поток-«потребитель». Критические разделы выделены в них полужирным шрифтом.

// Программа 4.5

1 int isDirectory(string FileName)

2 {

3 struct stat StatBuffer;

4

5 lstat(FileName.c_str(),&StatBuffer);

6 if((StatBuffer.st_mode & S_IFDIR) == -1)

7 {

8 cout << «could not get stats on file» << endl;

9 return(0);

10 }

11 else{

12 if(StatBuffer.st_mode & S_IFDIR){

13 return(1);

14 }

15 }

16 return(0);

17 }

18

19

20 int isRegular(string FileName)

21 {

22 struct stat StatBuffer;

23

24 lstat(FileName.c_str(),&StatBuffer);

25 if((StatBuffer.st_mode & S_IFDIR) == -1)

26 {

27 cout << «could not get stats on file» << endl;

28 return(0);

29 }

30 else{

31 if(StatBuffer.st_mode & S_IFREG){

32 return(1);

33 }

34 }

35 return(0);

36 }

37

38

39 void depthFirstTraversal(const char *CurrentDir)

40 {

41 DIR *DirP;

42 string Temp;

43 string FileName;

44 struct dirent *EntryP;

45 chdir(CurrentDir);

46 cout << «Searching Directory: " << CurrentDir << endl;

47 DirP = opendir(CurrentDir);

48

49 if(DirP == NULL){

50 cout << «could not open file» << endl;

51 return;

52 }

53 EntryP = readdir(DirP);

54 while(EntryP != NULL)

55 {

56 Temp.erase();

57 FileName.erase();

58 Temp = EntryP->d_name;

59 if((Temp != ".») && (Temp != "..»)){

60 FileName.assign(CurrentDir);

61 FileName.append(1,'/');

62 FileName.append(EntryP->d_name);

63 if(isDirectory(FileName)){

64 string NewDirectory;

65 NewDirectory = FileName;

66 depthFirstTraversal(NewDirectory.c_str());

67 }

68 else{

69 if(isRegular(FileName)){

70 int Flag;

71 Flag = FileName.find(".cpp»);

72 if(Flag > 0){

73 pthread_mutex_lock(&CountMutex);

74 FileCount++;

75 pthread_mutex_unlock(&CountMutex);

76 pthread_mutex_lock(&QueueMutex);

77 TextFiles.push(FileName);

78 pthread_mutex_unlock(&QueueMutex);

79 }

80 }

81 }

82

83 }

84 EntryP = readdir(DirP);

85 }

86 closedir(DirP);

87 }

88

89

90

91 void *task(void *X)

92 {

93 char *Directory;

94 Directory = static_cast<char *>(X);

95 depthFirstTraversal(Directory);

96 return(NULL);

97

98 }

Программа 4.6 содержит поток-«потребитель», который выполняет ных ключевых слов.

// Программа 4.6

1 void *keySearch(void *X)

2 {

3 string Temp, Filename;

4 less<string> Comp;

5

6 while(!Keyfile.eof() && Keyfile.good())

7 {

8 Keyfile >> Temp;

9 if(!Keyfile.eof()){

10 KeyWords.insert(Temp);

11 }

12 }

13 Keyfile.close();

14

15 while(TextFiles.empty())

16 { }

17

18 while(!TextFiles.empty())

19 {

20 pthread_mutex_lock(&QueueMutex);

21 Filename = TextFiles.front();

22 TextFiles.pop();

23 pthread_mutex_unlock(&QueueMutex);

24 Infile.open(Filename.c_str());

25 SearchWords.erase(SearchWords.begin(),SearchWords.end());

26

27 while(!Infile.eof() && Infile.good())

28 {

29 Infile >> Temp;

30 SearchWords.insert(Temp);

31 }

32

33 Infile.close();

34 if(includes(SearchWords.begin(),SearchWords.end(),

KeyWords.begin(),KeyWords.end(),Comp)){

35 Outfile << Filename << endl;

36 pthread_mutex_lock(&CountMutex);

37 FileCount--;

38 pthread_mutex_unlock(&CountMutex);

39 FoundCount++;

40 }

41 }

42 return(NULL);

43

44 }

Программа 4.7 содержит основной поток для потоков модели «изготовитель-потребитель», реализованных в программах 4.5 и 4.6.

// Программа 4.7

1 #include <sys/stat.h>

2 #include <fstream>

3 #include <queue>

4 #include <algorithm>

5 #include <pthread.h>

6 #include <iostream>

7 #include <set>

8

9 pthread_mutex_t QueueMutex = PTHREAD_MUTEX_INITIALIZER;

10 pthread_mutex_t CountMutex = PTHREAD_MUTEX_INITIALIZER;

11

12 int FileCount = 0;

13 int FoundCount = 0;

14

15 int keySearch(void);

16 queue<string> TextFiles;

17 set <string,less<string> >KeyWords;

18 set <string,less<string> >SearchWords;

19 ifstream Infile;

20 ofstream Outfile;

21 ifstream Keyfile;

22 string KeywordFile;

23 string OutFilename;

24 pthread_t Thread1;

25 pthread_t Thread2;

26

27 void depthFirstTraversal(const char *CurrentDir);

28 int isDirectory(string FileName);

29 int isRegular(string FileName);

30

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

32 {

33 if(argc != 4){

34 cerr << «need more info» << endl;

35 exit (1);

36 }

37

38 Outfile.open(argv[3],ios::app||ios::ate);

39 Keyfile.open(argv[2]);

40 pthread_create(&Thread1,NULL,task,argv[1]);

41 pthread_create(&Thread2,NULL,keySearch,argv[1]);

42 pthread_join(Thread1,NULL);

43 pthread_join(Thread2,NULL);

44 pthread_mutex_destroy(&CountMutex);

45 pthread_mutex_destroy(&QueueMutex);

46

47 cout << argv[1] << " contains " << FoundCount

<< " files that contains all keywords.» << endl;

48 return(0);

49 }

С помощью мьютексов доступ к разделяемой памяти для чтения или записи данных разрешается получить только одному потоку. Для гарантии безопасности работы функций, определенных пользователем, можно использовать и другие механизмы и методы, которые реализуют одну из моделей PRAM:

• EREW (монопольное чтение и монопольная запись)

• CREW (параллельное чтение и монопольная запись)

• ERCW (монопольное чтение и параллельная запись)

• CRCW (параллельное чтение и параллельная запись)

Мьютексы используются для реализации EREW-алгоритмов, которые рассматриваются в главе 5.

Безопасность использования потоков и библиотек

Климан (Klieman), Шах (Shah) и Смаалдерс (Smaalders) утверждали:

«Функция или набор функций могут сделать поток безопасным или реентерабельным (повторно-входимым), если эти функции могут вызываться не одним, а несколькими потоками без предъявления каких бы то ни было требований к вызывающей части выполнить определенные действия»(1996)

При разработке многопоточного приложения программист должен обеспечить безопасность параллельно выполняемых функций. Мы уже обсуждали безопасность функций, определенных пользователем, но без учета того, что приложение часто вызывает функции из системных библиотек или библиотек, созданных сторонними производителями. Одни такие функции и/или библиотеки безопасны для потоков, а другие — нет. Если функция небезопасна, это означает, что в ней используется хотя бы одна статическая переменная, осуществляется доступ к глобальным данным и/или она не является реентерабельной.

Известно, что статические переменные поддерживают свои значения между вызовами функции. Если некоторая функция содержит статические переменные, то для ее корректного функционирования требуется считывать (и/или изменять) их значения. Если же к такой функции будут обращаться несколько параллельно выполняемых потоков, возникнут условия «гонок». Если функция модифицирует глобальную переменную, то каждый из нескольких потоков, вызывающих функцию, может попытаться модифицировать эту глобальную переменную. Возникновения условий «гонок» также не миновать, если не синхронизировать множество параллельных доступов к глобальной переменной. Например, несколько параллельных потоков могут выполнять функции, которые устанавливают переменную errno. Для некоторых потоков, предположим, эта функция не может выполниться успешно, и переменная errno устанавливается равной сообщению об ошибке [10], в то время как другие потоки выполняются успешно. Если реализация компилятора не обеспечивает потоковую безопасность поддержки переменной errno, то какое сообщение получит поток при проверке состояния переменной errno?

Блок кода считается реентерабельным, если его невозможно изменить при выполнении. Реентерабельный код исключает возникновение условий «гонок» благодаря отсутствию ссылок на глобальные переменные и модифицируемые статические данные Следовательно, такой код могут совместно использовать несколько параллельных потоков или процессов без риска создать условия «гонок». Стандарт POSIX определяет ряд реентерабельных функций. Их легко узнать по наличию «суффикса» присоединяемого к имени функции. Перечислим некоторые из них:

getgrgid_r()

getgrnam_r()

getpwuid_r()

sterror_r()

strtok_r()

readdir_r()

rand_r()

ttyname_r()

Если функция получает доступ к незащищенным глобальным переменным, содержит статические модифицируемые переменные или нереентерабельна, то такая функция считается небезопасной для потока. Системные библиотеки или библиотеки созданные сторонними производителями, могут иметь различные версии своих стандартных библиотек. Одна версия предназначена для однопоточных приложений, а другая — для многопоточных. Если предполагается разрабатывать многопоточное приложение, программист должен использовать многопоточные версии нужной ему библиотеки. Некоторые среды требуют не компоновки многопоточных приложений с многопоточной версией библиотеки, а лишь определения макросов, что позволяет объявить реентерабельные версии функций. Такое приложение будет затем компилироваться как безопасное для выполнения потоков.

Во всех ситуациях использовать многопоточные версии функций попросту невозможно. В отдельных случаях многопоточные версии конкретных функций недоступны для данного компилятора или среды. Иногда один интерфейс функции не в состоянии сделать ее безопасной. Кроме того, программист может столкнуться с увеличением числа потоков в среде, которая изначально использовала функции, предназначенные для функционирования в однопоточной среде. В таких условиях обычно используются мьютексы. Например, программа имеет три параллельно выполняемых потока. Два из них, thread1 и thread2, параллельно выполняют функцию funcA(), которая не является безопасной для одновременной работы потоков. Третий поток, thread3, выполняет функцию funcB (). Для решения проблемы, связанной с функцией funcA (), возможно, достаточно заключить в защитную оболочку мьютекса доступ к ней со стороны потоков threadl и thread2:

thread1 thread2 thread3

{ { {

lock() lock() funcB()

funcA() funcA() }

unlock() unlock()

} }

При реализации таких защитных мер к функции funcA () в любой момент времени может получить доступ только один поток. Но проблемы на этом не исчерпываются. Если обе функции funcA() и funcB() небезопасны для выполнения потоками, они могут обе модифицировать глобальные или статические переменные. И хотя потоки thread1 и thread2 используют мьютексы для функции funcA (), поток thread3 может выполнять функцию funcB одновременно с любым из остальных потоков. В такой ситуации вполне вероятно возникновение условий «гонок», поскольку функции funcA () и funcB () могут модифицировать одну и ту же глобальную или статическую переменную.

Проиллюстрируем еще один тип условий «гонок», возникающих при использовании библиотеки i ostream. Предположим, у нас есть два потока, А и В, которые выводят данные в стандартный выходной поток, cout, который представляет собой типа ostream. При использовании операторов ">>" и "<<" вызываются методы объекта cout. Вопрос: являются ли эти методы безопасными? Если поток A от правляет сообщение «Мы существа разумные» объекту stdout, а поток В отправляет сообщение «Люди алогичные существа», то не произойдет ли «перемешивание» выходных данных, в результате которого может получиться сообщение вроде такого- " Мы Люди существа алогичные разумные существа»? В некоторых случаях безопасные для потоков функции реализуются как атомные. Атомные функции — это функции, ко торые, если их выполнение началось, не могут быть прерваны. Если операция ">>" для объекта cout реализована как атомная, то подобное «перемешивание» не произойдет. Если есть несколько обращений к оператору ">>", то они будут выполнены последовательно. Сначала отобразится сообщение потока А, а затем сообщение потока В или наоборот, хотя они вызвали функцию вывода одновременно. Это — пример преобразования параллельных действий в последовательные, которое обеспечит безопасность выполнения потоков. Но это не единственный способ обезопасить функцию. Если функция не оказывает неблагоприятного эффекта, она может смешивать свои операции. Например, если метод добавляет или удаляет элементы из структуры, которая не отсортирована, и этот метод вызывают два различных потока, то перемешивание их операций не даст неблагоприятного эффекта.

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

• Ограничить использование всех опасных функций одним потоком.

• Не использовать безопасные функции вообще.

• Собрать все потенциально опасные функции в один набор механизмов синхронизации.

Еще один вариант — создать интерфейсные классы для всех опасных функций, которые должны использоваться в многопоточном приложении, т.е. опасные функции инкапсулируются в одном интерфейсном классе. Такой интерфейсный класс может быть скомбинирован с соответствующими объектами синхронизации с помощью наследования или композиции и использован специализированным классом. Такой подход устраняет возможность возникновения условий «гонок».

Разбиение программы на несколько потоков

Выше в этой главе мы рассматривали делегирование работы в соответствии с конкретной стратегией или потоковой моделью. Итак, используются следующие распространенные модели:

• делегирование («управляющий-рабочий»");

• сеть с равноправными узлами;

• конвейер;

• «изготовитель-потребитель».

Каждая модель характеризуется собственной декомпозицией работ (Work Breakdown Structure — WBS), которая определяет, кто отвечает за создание потоков и при каких условиях они создаются. В этом разделе мы рассмотрим пример программы для каж дой модели, использующей функции библиотеки Pthread.

Использование модели делегирования

Мы рассмотрели два подхода к реализации модели делегирования при разделении мы на потоки. Вспомним: в модели делегирования один поток (управляющий) создает другие потоки (рабочие) и назначает каждому из них задачу. Управляющий поток делегирует каждому рабочему потоку задачу, которую он должен выполнить, путем задания некоторой функции. При одном подходе управляющий поток создает рабочие потоки как результат запросов, обращенных к системе. Управляющий поток обрабатывает запрос каждого типа в цикле событий. Как только событие произойдет, будет создан рабочий поток и ему будет назначена задача. Функционирование цикла событий в управляющем потоке и создание рабочих потоков продемонстрировано в листинге 4 .5.

// Листинг 4.5. Подход 1: скелет программы реализации II   модели управляющего и рабочих потоков

//...

pthread_mutex_t Mutex = PTHREAD_MUTEX_INITIALIZER

int AvailableThreads

pthread_t Thread[Max_Threads]

void decrementThreadAvailability(void)

void incrementThreadAvailability(void)

int threadAvailability(void);

// boss thread

{

//...

if(sysconf(_SC_THREAD_THREADS_MAX) > 0){

AvailableThreads = sysconf(_SC_THREAD_THREADS_MAX)

}

else{

AvailableThreads = Default

}

int Count = 1;

loop while(Request Queue is not empty)

if(threadAvailability()){

Count++

decrementThreadAvailability()

classify request

switch(request type)

{

case X : pthread_create(&(Thread[Count])...taskX...)

case Y : pthread_create(&(Thread[Count])...taskY...)

case Z : pthread_create(&(Thread[Count])...taskZ...)

//...

}

}

else{

//free up thread resources

}

end loop

}

void *taskX(void *X)

{

// process X type request

incrementThreadAvailability()

return(NULL)

}

void *taskY(void *Y)

{

// process Y type request

incrementThreadAvailability()

return(NULL)

}

void *taskZ(void *Z)

{

// process Z type request

decrementThreadAvailability()

return(NULL)

}

В листинге 4.5 управляющий поток динамически создает поток для обработки каждого нового запроса, который поступает в систему. Однако существует ограничение на количество потоков (максимальное число потоков), которое можно создать в процессе. Для обработки n типов запросов существует n задач. Чтобы гарантировать, что максимальное число потоков на процесс не будет превышено, определяются следующие дополнительные функции:

threadAvailability()

incrementThreadAvailability()

decrementThreadAvailability()

В листинге 4.6 содержится псевдокод реализации этих функций.

// Листинг 4.6. Функции, которые управляют возможностью

// создания потоков

void incrementThreadAvailability(void)

{

//...

pthread_mutex_lock(&Mutex)

AvailableThreads++

pthread_mutex_unlock(&Mutex)

}

void decrementThreadAvailability(void)

{

//...

pthread_mutex_lock(&Mutex)

AvailableThreads—

pthread_mutex_unlock(&Mutex)

}

int threadAvailability(void)

{

//...

pthread_mutex_lock(&Mutex)

if(AvailableThreads > 1)

return 1

else

return 0

pthread_mutex_unlock(&Mutex)

}

Ф ункция threadAvailability() возвратит число 1, если максимально допустимое количество потоков для процесса еще не достигнуто. Эта функция опрашивает глобальную переменную ThreadAvailability, в которой хранится число потоков, еще доступных для процесса. Управляющий поток вызывает функцию decrementThreadAvailability(), которая декрементирует эту глобальную переменную до создания им рабочего потока. Каждый рабочий поток вызывает функцию incrementThreadAvailability(), которая инкрементирует глобальную переменную ThreadAvailability до начала его выполнения. Обе функции содержат обращение к функции pthread_mutex_lock () до получения доступа к этой глобальной переменной и обращение к функции pthread_mutex_unlock() после него. Если максимально допустимое количество потоков превышено, управляющий поток может отменить создание потока, если это возможно, или породить другой процесс, если это необходимо. Функции taskX(), taskY () и taskZ () выполняют код, предназначенный для обработки запроса соответствующего типа.

Другой подход к реализации модели делегирования состоит в создании управляющим потоком пула потоков, которым (вместо создания под каждый новый запрос нового потока) переназначаются новые запросы. Управляющий поток во время инициализации создает некоторое количество потоков, а затем каждый созданный поток приостанавливается до тех пор, пока в очередь не будет добавлен новый запрос. Управляющий поток для выделения запросов из очереди по-прежнему использует цикл событий. Но вместо создания нового потока для обслуживания очередного запроса, управляющий поток уведомляет уже существующий поток о необходимости обработки запроса. Этот подход к реализации модели делегирования представлен в листинге 4.7.

// Листинг 4.7. Подход 2: скелет программы реализации . модели управляющего и рабочих потоков

pthread_t Thread[N]

// boss thread

{

pthread_create(&(Thread[1]...taskX...);

pthread_create(&(Thread[2]...taskY...);

pthread_create(&(Thread[3]...taskZ...);

//...

loop while(Request Queue is not empty

get request

classify request

switch(request type)

{

case X :

enqueue request to XQueue

signal Thread[1]

case Y :

enqueue request to YQueue

signal Thread[2]

case Z :

enqueue request to ZQueue

signal Thread[3]

//...

}

end loop

}

void *taskX(void *X)

{

loop

suspend until awaken by boss

loop while XQueue is not empty

dequeue request

process request

end loop

until done

{

void *taskY(void *Y)

{

loop

suspend until awaken by boss

loop while YQueue is not empty

dequeue request

process request

end loop

until done

}

void *taskZ(void *Z)

{

loop

suspend until awaken by boss

loop while (ZQueue is not empty)

dequeue request

process request

end loop

until done

} //.. .

В листинге 4.7 управляющий поток создает N рабочих потоков (по одному для каждого типа задачи). Каждая задача связана с обработкой запросов некоторого типа В цикле событий управляющий поток извлекает запрос из очереди запросов, определяет его тип, ставит его в очередь запросов, соответствующую типу, а затем оправляет сигнал потоку, который обрабатывает запросы из этой очереди. Функции потоков также содержат циклы событий. Поток приостанавливается до тех пор, пока не получит сигнал от управляющего потока о существовании запроса в его очереди. После «пробуждения» (уже во внутреннем цикле) поток обрабатывает все запросы до тех пор, пока его очередь не опустеет.

Использование модели сети с равноправными узлами

В модели равноправных узлов один поток сначала создает все потоки, необходимые выполнения всех задач. Каждый из равноправных потоков обрабатывает запросы, поступающие из собственного входного потока данных. В листинге 4.8 представлен скелет программы, реализующий при разделении программы на потоки метод равноправных узлов

Листинг 4.8. Скелет программы реализации модели  равноправных потоков

pthread_t Thread[N]

// initial thread

{

pthread_create(&(Thread[1]...taskX...);

pthread_create(&(Thread[2]...taskY...);

pthread_create(&(Thread[3]...taskZ...);

//...

}

void *taskX(void *X)

{

loop while (Type XRequests are available)

extract Request

process request

end loop

return(NULL)

}

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

Использование модели конвейера

В модели конве йера поток входных данных обрабатывается поэтапно. На каждом этапе некоторая порция работы (часть входного потока данных) обрабатывается одним потоком выполнения, а затем передается для обработки следующему. Каждая порция входных данных переходит на очередной этап обработки до тех пор, пока не будет завершена вся обработка. Такой подход позволяет обрабатывать несколько входных потоков данных одновременно. Каждый поток выполнения отвечает за достижение пром ежуточного результата, делая его доступным для следующего этапа (т.е. следующего потока конвейера). Скелет программы реализации модели конвейера представлен в листинге 4.9.

// Листинг 4.9. Скелет программы реализации модели конвейера

//...

pthread_t Thread[N]

Queues[N]

// initial thread

{

place all input into stage1's queue

pthread_create(&(Thread[1]...stage1...);

pthread_create(&(Thread[2]...stage2...);

pthread_create(&(Thread[3]...stage3...);

//...

}

void *stageX(void *X)

{

loop

suspend until input unit is in queue

loop while XQueue is not empty

dequeue input unit

process input unit

enqueue input unit into next stage's queue

end loop

until done

return(NULL)

}

В листинге 4.9 объявляется N очередей для N этапов. Начальный поток помещает все порции входных потоков в очередь первого этапа, а затем создает все потоки, необходимые для выполнения всех этапов. Каждый этап содержит свой цикл событий. Поток выполнения находится в состоянии ожидания до тех пор, пока в его очереди не появится порция входных данных. Внутренний цикл продолжается до опустения соответствующей очереди. Порция входных данных извлекается из очереди, обрабатывается, а затем помещается в очередь следующего этапа обработки (следующего потока выполнения).

Использование модели «изготовитель-потребитель»

В модели «изготовитель-потребитель» поток- «изготовитель» готовит данные, «потребляемые» потоком-«потребителем» (причем таких потоков-«потребителей" может быть несколько). Данные хранятся в блоке памяти, разделяемом всеми потока, как изготовителем, так и потребителями. В листинге 4.10 представлен скелет программы реализации модели «изготовитель-потребитель» (эта модель также использовалась в программах 4.5, 4.6 и 4.7).

Листинг 4.10. Скелет программы реализации модели «изготовитель-потребитель»

pthread_mutex_t Mutex = PTHREAD_MUTEX_INITIALIZER

pthread_t Thread[2]

Queue

// initial thread

{

pthread_create(&(Thread[1]...producer...);

pthread_create(&(Thread[2]...consumer...);

//...

}

void *producer(void *X)

{

loop

perform work

pthread_mutex_lock(&Mutex)

enqueue data

pthread_mutex_unlock(&Mutex)

signal consumer

//...

until done

}

void *consumer(void *X)

{

loop

suspend until signaled

loop while(Data Queue not empty)

pthread_mutex_lock(&Mutex)

dequeue data

pthread_mutex_unlock(&Mutex)

perform work

end loop

until done

}

//

В листинге 4.9 начальный поток создает оба потока: «изготовителя» и «потребителя». Поток- «изготовитель» содержит цикл, в котором после выполнения некоторых действий блокируется мьютекс для совместно используемой очереди, чтобы поместить в нее подготовленные для потребителя данные. После этого «изготовитель» деблокирует мьютекс и посылает сигнал потоку- «потребителю» о том, что ожидаемые им данные уже находятся в очереди. Поток- «изготовитель» выполняет итерации цикла до тех пор, пока не будет выполне н а вся работа. Поток- «потребитель» также выполняет цикл, в котором он приостанавливается до тех пор, пока не получит сигнал. Во внутреннем цикле поток- «потребитель» обрабатывает все данные до тех пор, пока не опустеет очередь. Он блокирует мьютекс для разде л яемой очереди перед извлечением из нее данных и деблокирует мьютекс после этого. Затем он выполняет обработку извлеченных данных. В программе 4.6 поток-«потребитель» помещает свои результаты в файл. Вместо файла может быть использована другая структура данных. Зачастую потоки-«потребители» играют две роли: как потребителя, так и изготовителя. Сначала возможно «исполнение» роли потребителя необработанных данных, подготовленных потоком-«изготовителем», а затем поток играет роль «изготовителя», когда он обрабатывает данные, сохраняемые в другой совместно используемой очереди, «потребляемой» другим потоком.

Создание многопоточных объектов

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

В любом случае потоки объявляются в рамках объекта и создаются одной из функций-членов (например, конструктором). Потоки могут затем выполнять некоторые независимые функции (функции, определенные вне объекта), которые вызывают функции-члены глобальных объектов. Это — один из способов создания многопоточного объекта. Пример многопоточного объекта представлен в листинге 4.10.

// Листинг 4.11 . Объявление и определение многопоточного

// объекта

#include <pthread.h>

#include <iostream>

#include <unistd.h>

void *taskl(void *);

void *task2(void *);

class multithreaded_object {

pthread_t Threadl,

Thread2; public:

multithreaded_object(void);

int cl(void);

int c2(void);

//.. .

);

multithreaded_object::multithreaded_object(void) {

//. . .

pthread_create(&Threadl, NULL, taskl, NULL); pthread_create(&Thread2 , NULL, task2 , NULL);

pthread_join(Threadl, NULL);

pthread_join(Thread2 , NULL);

//. . .

}

int multithreaded_object::cl(void) {

// Выполнение действий,

return(1);

}

int multithreaded_object::c2(void) {

// Выполнение действий,

return(1);

}

multithreaded_object MObj;

void *taskl(void *) {

//...

MObj.cl() ; return(NULL) ;

}

void *task2(void *) {

//...

M0bj.c2(); return(NULL) ;

}

В листинге 4.11 в классе multithread_object объявляются два потока. Они создаются и присоединяются к основному потоку в конструкторе этого класса. Поток Thread1 выполняет функцию task1 (), а поток Thread2 — функцию task2 (). Функции taskl () и task2 () затем вызывают функции-члены глобального объекта MObj.

Резюме

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

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

Для создания и управления потоками многопоточного приложения можно использовать библиотеку Pthread. Библиотека Pthread опирается на стандартизированный программный интерфейс, предназначенный для создания и поддержки потоков Этот интерфейс определен комитетом стандартов IEEE в стандарте POSIX 1003.1с Сторонние производители при создании своих продуктов должны придерживаться этого стандарта POSIX.

Синхронизация параллельно выполняемых задач

Отношение этих механизмов ко времени требует тщательного изучения. <...> Нас почти не интересовала производительность вычислительной машины для одного входного сигнала. Чтобы адекватно функционировать, она должна показывать удовлетворительную производительность для целого класса входных сигналов, а это будет означать удовлетворительную производительность для класса входных сигналов, получение которого ожидается статистически...

Ho6epr Винер (Norbert Wiener), Кибернетика

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

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

Координация порядка выполнения потоков

Предположим, у нас есть три параллельно выполняющихся потока — А, В и С. Все они участвуют в обработке списка. Список необходимо отсортировать, выполнить в нем операции поиска и вывода результатов. Каждому потоку назначается отдельная задача. Так, поток А должен отобразить результаты поиска, В — отсортировать список, а С — провести поиск. Сначала список необходимо отсортировать, затем выполнить несколько параллельных операций поиска, а уж потом отобразить результаты. Если задачи, выполняемые потоками, не синхронизировать надлежащим образом, то поток А может попытаться отобразить еще не сгенерированные результаты, что нарушит постусловие, или выхо д ное условие (postcondition), процесса. Предусловием, или вхо д ным условием (precondition), з д есь является необходимость получения отсортированно г о списка до выполнения в нем поиска. Поиск в неотсортированном списке может дать неверные результаты. Поэтому для этих трех потоков необходимо обеспечить синхронизацию задач, которая приводит в исполнение постусловия и предусловия ло г ических процессов. UML-диаграмма видов деятельности для этого процесса представлена на рис. 5 .1.

Сначала поток В должен отсортировать список, затем эстафета управления передается «мно г оканальному» поиску, порождаемому потоком С. И только после завершения поисковых работ по всем направлениям поток А отображает результаты поиска.

Взаимоотношения между синхронизируемыми задачами

Существует четыре основных типа отношений синхронизации между любыми двумя потоками в одном процессе или между любыми двумя процессами в одном приложении: старт-старт (CC), финиш-старт (ФС), старт-финиш (СФ) и финиш-финиш (ФФ). С помощью этих основных типов отношений можно охарактеризовать координацию задач между потоками и процессами. UML-диаграмма видов деятельности для каждого типа отношений синхронизации показана на рис. 5.2.

Рис. 5.1. Диаграмма видов деятельности для задач сортировки списка, поиска и отображения результатов поиска

Отношения типа старт-старт (CC)

В отношениях синхронизации типа старт-старт одна задача не может начаться до тех пор, пока не начнется другая. Одна задача может начаться раньше другой, нo не позже. Предположим, у нас есть программа, которая реализует инкарнацию (воплощение). Инкарнация «материализуется» в виде говорящей головы, созданной, разумеется, компьютерной программой. Инкарнация обеспечивает своего рода «одушевление» программ. Программа, которая реализует «одушевление», имеет несколько потоков. Здесь нас в первую очередь интересует поток А, который «отвечает» за анимацию результата, и поток В, который управляет звуком, или голосом, говорящей головы. Мы хотим создать иллюзию синхронизации звука и движений рта. В идеале они должны происходить абсолютно одновременно. При наличии нескольких процессоров оба потока могут начинаться одновременно. Эти потоки связаны отношением типа старт - старт. В соответствии с условиями временной синхронизации допускается, чтобы поток А начинался немного раньше потока В (именно немного — иначе будет нарушена иллюзия одновременности), но поток В не может начаться раньше потока А. Голос должен ожидать анимацию, а не наоборот. Совершенно нежелательно услышать голос до того, как зашевелятся губы (если это не синхронное озвучивание).

Рис. 5.2. Возможные отношения синхронизации между задачами А и В

Отношения типа финиш-старт (ФС)

В отношениях синхронизации типа финиш-старт задача А не может завершиться до тех пор, пока не начнется задача В. Этот тип отношений типичен для родительско-сыновних процессов. Родительский процесс не может завершить выполнение некоторых операций до тех пор, пока не будет сгенерирован сыновний процесс или пока не будет получена обратная связь от сыновнего процесса, который начал выполнение. Сыновний процесс, «просигналивший» родителю или предоставивший ему необходимую информацию, продолжает выполняться, а родительский процесс после этого может завершиться.

Отношения типа старт-финиш (СФ)

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

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

Отношения типа финиш-финиш (ФФ)

В отношениях синхронизации типа финиш-финиш одна за д ача не может завершиться до тех пор, пока не завершится другая, т.е. задача А не может финишировать до задачи В. Этот тип отношений можно применить к описанию отношений между родительскими и сыновними процессами, которые рассматривались в главе 3. Родительский процесс должен ожидать до тех пор, пока не завершатся все сыновние процессы, и только потом сможет завершиться сам. Если описанная последовательность нарушится, и родительский процесс финиширует раньше своих потомков, то эти завершенные сыновние процессы перейдут в зомбированное состояние. Родительские процессы не должны завершаться (выходить из системы в данном случае) до тех пор, пока не выполнятся до конца их сыновние процессы. Для родительских процессов это достигается за счет вызова функции wait() для каждого из своих сыновних процессов либо ожидания деблокировки (освобождения) мьютекса или условной переменной, что может быть осуществлено сыновними потоками. Еще одним примером отношений типа финиш-финиш может служить модель «управляющий-рабочий». Задача управляющего потока — делегировать работу рабочим потокам. Для управляющего крайне нежелательно завершить работу раньше рабочих. В этом случае не были бы обработаны новые запросы к системе, не имели работы существующие потоки и не создавались новые. Если управляющий поток является основным потоком процесса, и он завершается, то процесс должен завершиться вместе со всеми рабочими потоками. Если в модели равноправных потоков поток А динамически создает объект, передаваемый потоку В, и поток А затем завершается, то вместе с ним разрушается и созданный им объект. Если это произойдет до того, как поток В получит возможность использовать этот объект, возникнет ошибка сегментации или нарушится доступ к данным Чтобы предотвратить возникновение этого типа ошибок, завершение потоков синхронизируется с помощью функции pthread_join(). Обращение к этой функции заставляет вызывающий поток ожидать до тех пор, пока не финиширует заданный поток. Таким образом и создается синхронизация типа финиш-финиш.

Синхронизация доступа к данным

Существует разница между данными, раздел я емыми между процессами, и данными, разделяемыми между потоками. Потоки совместно используют одно и то же адресное пространство, в то время как процессы имеют отдельные адресные пространства. Если существуют два процесса А и В, то данные, объявленные в процессе А, недоступны процессу В, и наоборот. Следовательно, один из методов, используемых процессами для разделения данных, состоит в создании блока памяти, отображаемого затем на адресное пространство процессов, которые должны разделять память. Другой подход предполагает создание блока памяти, существующего вне адресного пространства обоих процессов. К типам механизмов межпроцессного взаимодействия (МПВ) относятся каналы, файлы и передача сообщений.

Именно блок памяти, разделяемый между потоками внутри одного и того же адресного пространства, и блок памяти, раздел я емый между процессами вне обоих адресных пространств, требует синхронизации данных. Память, разделяемая между потоками и процессами, показана на рис. 5 .3.

Синхронизация данных необходима для управления состоянием «гонок», а также для того, чтобы позволить параллельным потокам или процессам безопасно получить доступ к блоку памяти. Синхронизация данных позволяет управлять считыванием и модификацией данных в блоке памяти. В многопоточной среде параллельный доступ к общей памяти, глобальным переменным и файлам обязательно должен быть синхронизирован. Что касается программного кода задачи, то синхронизация данных необходима в тех его блоках, где делается попытка получить доступ к блоку памяти, глобальным переменным или файлам, разделяемым с другими параллельно выполняемыми процессами или потоками. Такие блоки кода называются критическими разделами. В качестве критического раздела может выступать любой блок кода, который изменяет позицию файлового указателя, записывает данные в файл, закрывает файл и считывает или устанавливает глобальные переменные либо структуры данных. Выделение таких задач, которые выполняют чтение или запись данных, является одним из этапов управления параллельным доступом к совместно используемой памяти.

Модель РРАМ

Модель PRAM (Parallel Random-Access Machine — машина с параллельным произвольным доступом) — это упрощенная модель с N процессорами, обозначаемыми P 1 , Р 2 , Р 5 , ... Р n , которые разделяют одну глобальную память. Все процессоры одновременно получают доступ для чтения и записи к совместно используемой глобальной памяти. Каждый из этих теоретических процессоров может получить доступ к разделяе м ой глобальной памяти в течение одного непрерываемого интервала времени. Модель PRAM включает алгоритмы параллельного, а также исключающего чтения и записи. Алгоритмы параллельного чтения позволяют нескольким процессорам одновременно использовать одну и ту же область памяти без како г о бы то ни было искажения данных. Алгоритмы параллельной записи позволяют нескольким процессорам записывать данные в разделяемую область памяти. Алгоритмы исключающего чтения используются для получения гарантии того, что никакие два процессора никогда не будут считывать информацию из одной и той же области памяти одновременно. Алгоритмы исключающей записи гарантируют, что никакие два процессора никогда не будут записывать данные в одну и ту же область памяти одновременно. Модель PRAM можно использовать для определения характера параллельного доступа к общей памяти со стороны нескольких задач.

Рис. 5.3. Память, разделяемая между потоками и процессами

Параллельный и исключающий доступ к памяти

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

• исключаю щ ее чтение и исключаю щ ая запись (exclusive read and exclusive write-EREW);

• параллельное чтение и исключающая запись (concurrent read and exclusive write-CREW);

• исключаю щ ее чтение и параллельная запись (exclusive read and concurrent write-ERCW);

• параллельное чтение и параллельная запись (concurrent read and concurrent write-CRCW).

Эти алгоритмы можно рассматривать как стратегии доступа, реализуемые задачами, которые совместно используют данные (рис. 5.4). Алгоритм EREW подразу м евает последовательный доступ к разделяемой памяти, т.е. к общей памяти в любой момент времени может получить доступ только одна задача. Примером стратегии доступа EREW может служить вариант реализации модели потоков «производитель-потребитель», рассмотренный в главе 4. Доступ к очереди, содержащей имена файлов, может быть ограничен исключающей записью «изготовителя» и исключающим чтением «потребителя». В любой момент времени доступ к очереди может быть разрешен только для одной задачи. Стратегия CREW позволяет множественный доступ для чтения общей памяти и исключающий доступ для записи в нее данных. Это означает отсутствие ограничений на количество задач, которые могут одновременно читать разделяемую память, но записывать в нее данные может только одна задача. При этом параллельное чтение может происходить одновременно с записью данных в общую память. При использовании этой стратегии доступа все читающие задачи могут прочитать различные значения, поскольку во время чтения значения из общей памяти записывающая задача может его модифицировать. Стратегия доступа ERCW — это прямая противоположность стратегии CREW. При использовании стратегии ERCW разрешены параллельные записи в общую память, но лишь одна задача может читать ее в любой момент времени. Стратегия доступа CRCW позволяет множеству задач выполнять параллельное чтение и запись.

Для этих четырех типов алгоритмов требуются различные уровни и типы синхронизации. Их диапазон довольно широк: от стратегии доступа, реализация которой требует минимальной синхронизации, до стратегии доступа, реализация которой требует максимальной синхронизации. Наша задача— реализовать эти стратегии, поддерживая целостность данных и удовлетворительную производительность системы. EREW — самая простая для реализации стратегия, поскольку она предполагает, по сути, только последовательную обработку. На первый взгляд самой простой может показаться стратегия CRCW, но она таит в себе массу трудностей. А ведь это только кажется, что если к памяти можно получить доступ без ограничений, то в ней и речь не идет о какой бы то ни было стратегии. Все как раз наоборот: CRCW — самая трудная для реализации стратегия, которая требует максимальной синхронизации.

Рис. 5.4. Стратегии доступа EREW, CREW, ERCW и CRCW

Что такое семафоры

Семафор — это механизм синхронизации, который можно использовать для управления отношениями между параллельно выполняющимися программными компонентами и реализации стратегий доступа к данным. Семафор — это переменная специального вида, которая может быть доступна только для выполнения узкого диапазона операций. Семафор используется для синхронизации доступа процессов и потоков к разделяемой модифицируемой памяти или для управления доступом к устройствам или другим ресурсам. Семафор можно рассматривать как ключ к ресурсам. Этим ключом может владеть в любой момент времени только один процесс или поток. Какал бы задача ни владела этим ключом, он надежно запирает (блокирует) нужные ей ресурсы для ее монопольного использования. Блокирование ресурсов заставляет другие задачи, которые желают воспользоваться этими ресурсами, ожидать до тех пор, пока они не будут разблокированы и снова станут доступными. После разблокирования ресурсов следующая задача, ожидающая семафор, получает его и доступ к ресурсам. Какал задача будет следующей, определяется стратегией планирования, действующей для данного потока или процесса.

Операции по управлению семафором

Как упоминалось выше, к семафору можно получить доступ только с помощью специальных операций, подобных тем, которые выполняются с объектами. Это операции декремента, P(), и инкремента, V(). Если объект Mutex представляет собой семафор, то логика реализации операций P (Mutex) и V (Mutex) м ожет выглядеть таки м образо м:

P(Mutex)

if (Mutex > 0) {

Mutex--;

} else {

Блокирование по объекту Mutex;

}

V(Mutex)

if(Oчepeдь доступа к объекту Mutex не пуста){

Передача объекта Мьютекс следующей задаче;

} else {

Mutex++;

}

Реализация зависит от конкретной систе м ы. Эти операции неделимы, т.е. их невозможно прервать. Если операцию P () попытаются выполнить сразу несколько задач, то лишь одна из них получит разрешение продолжить работу. Если объект Mutex был уже декре м ентирован, то задача будет заблокирована и зай м ет м есто в очереди. Операци я V () вызываетс я задачей, которая и м еет доступ к объекту Mutex. Если получения доступа к объекту Мьютекс ожидают дру г ие задачи, он «передается » следующей задаче из очереди. Если очередь задач пуста, объект Mutex инкрементируетс я.

Операции с семафором могут иметь другие имена:

Операци я P(): lock()

Операци я V(): unlock()

Значение семафора зависит от его типа. Двоичный семафор будет иметь значение 0 или 1. Вычислительный семафор (определяю щ ий лимиты ресурсов для процессов, получающих доступ к ним) может иметь некоторое неотрицательное целочисленное значение.

Стандарт POSIX определяет несколько типов семафоров. Эти семафоры испо л ьзуются процессами или потоками. Типы семафоров (а также их некоторые основные операции) перечислены в табл. 5.1.

Таблица 5 .1. Типы семафоров, определенные стандартом POSIX

Тип семафора

Пользователь

Описание

Мьютексный семафор

Процессы или потоки

Механизм, используемый для реализации взаимного исключения в критическом разделе кода

Блокировка для обеспечения чтения и записи

Процессы или потоки

Механизм, используемый для реализации стратегии доступа для чтения и записи среди потоков

Условная переменная

Процессы или потоки

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

Событийный мьютекс остается заблокированным потоком до тех пор, пока не будет получен соответствующий сигнал

Несколько условных переменных

Процессы или потоки

Аналогичен событийному мьютексу, но включает несколько событий или условий

Операционные системы, которые не противоречат спецификации Single UNIX Specification или стандарту POSIX Standard, поддерживают реализацию семафоров, которые являются частью библиотеки libpthread (соответствующие функции объявлены в заголовке pthread. h).

Мьютексные семафоры

Стандарт POSIX определяет мьютексный семафор, используемый потоками и процессами, как объект типа pthread_mutex_t. Этот мьютекс обеспечивает базовые операции, необходимые для функционирования практического механизма синхронизации:

• инициализация;

• запрос на монопольное использование;

• отказ от монопольного использования;

• тестирование монопольного использования;

• разрушение.

Функции класса pthread_mutex_t, которые используются для выполнения этих базовых операций, перечислены в табл. 5.2. Во время инициализации выделяется память, необходимая для функционирования мьютексного семафора, и объекту семафора присваивается некоторое начальное значение. Для двоичного семафора начальным может быть значение 0 или 1. Начальным значением вычислительного семафора может быть неотрицательное число, которое представляет количество доступных ресурсных единиц. Семафорное значение можно использовать для представления предельного количества запросов, которое способна обработать программа в одном сеансе. В отличие от обычных переменных, в инициализации которых сомневаться не приходится, факт инициализации мьютекса с помощью вызова соответствующей функции гарантировать невозможно. Чтобы убедиться в том, что мьютекс проинициализирован, необходимо после вызова операции инициализации принять некоторые меры предосторожности (например, проверить значение, возвращаемое соответствующей мьютекс-ной функцией, или значение переменной errno). Системе не удастся создать мьютекс, если окажется, что занята память, предусмотренная ранее для мьютексов, или превышено допустимое количество семафоров, или семафор с данным именем уже существует, или же имеет место какая-то другая проблема, связанная с выделением памяти.

Таблица 5.2. Фу н кции класса pthread_mutex_t

Инициализация int pthread_mutex_init( pthread_mutex_t *restrict mutex, const pthread_mutexattr_t *restrict attr);

pthread_mutex_t mutex =PTHREAD_MUTEX_INITIALIZER;

Запрос на монопольное использование #include <pthread.h>

<time.h>

int pthread_mutex_lock(pthread_mutex_t *mutex);

int pthread_mutex_timedlock(pthread_mutex_t *restrict mutex,

const struct timespec *restrict abs_timeout);

Отказ от монопольного использо вания int pthread_mutex_unlock(pthread_mutex_t *mutex);

Тестирование монопольно г о использования int pthread_mutex_trylock(pthread_mutex_t *mutex);

Разрушение int pthread_mutex_destroy(

pthread_mutex_t *mutex);

Подобно потокам, мьютекс библиотеки Pthread имеет атрибутный объект (он рассматривается ниже), который инкапсулирует все атрибуты мьютекса. Этот атрибутный объект можно передать функции инициализации, в результате чего будет создан мьютекс с атрибутами, заданными с помощью этого объекта. Если при инициализации атрибутный объект не используется, мьютекс будет инициализирован значениями, действую щ ими по умолчанию. Объект типа pthread_mutex_t инициализируется как деблокированный и закрытый. Закрытый мьютекс разделяется между потоками одно г о процесса. Разделяемый мьютекс совместно используется потоками нескольких процессов. При использовании атрибутов, действую щ их по умолчанию, мьютекс может быть инициализирован статически для статических мьютексных объектов с помощью следующего макроса:

pthread_mutex_t Mutex = PTHREAD_MUTEX_INITIALIZER; [11]

Этот метод менее затратный, но в нем не предусмотрено проверки ошибок.

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

Операция тестирования монопольного использования предназначена для проверки доступности мьютекса. Если он занят, функция возвра щ ает соответствующее значение. Достоинство этой операции состоит в том, что поток или процесс (в случае недоступности мьютекса) не блокируется и может продолжать выполнение. Если же мьютекс свободен, вызывающему потоку или процессу предоставляется право владения запрашиваемым мьютексом.

При выполнении операции разрушения освобождается память, связанная с мьютексом. Память не освобождается, если у мьютекса есть владелец или если поток (или процесс) ожидают права на владение им.

Использование мьютексного атрибутного объекта

Мьютексный объект типа pthread_mutex_t можно использовать вместе с атрибутным объектом подобно атрибутно м у объекту потока. Мьютексный атрибутный объект инкапсулирует все атрибуты объекта м ьютекса. После инициализации его м огут использовать несколько м ьютексных объектов, передавал в качестве пара м етра функции pthread_mutex_init (). Мьютексный атрибутный объект определяет ряд функций, используемых для установки таких атрибутов, как предельный приоритет, протокол и тип. Эти и другие функции м ьютексного атрибутного объекта перечислены в табл. 5.3.

Таблица 5.3. Функции доступа к мьютексному атрибу т ному объекту

Прототипы функций

Описание

int pthread_mutexattr_init (pthread_mutexattr_t * attr);

Инициализирует мьютексный атрибутный объект, заданный параметром attr, значениями, действующими по умолчанию для всех атрибутов, определяемых реализацией

int pthread_mutexattr_destroy (pthread_mutexattr_t * attr);

Разрушает мьютексный атрибутный объект, заданный параметром attr, в результате чего он становится неинициализированным. Его можно инициализировать повторно с помощью функции pthread_mutexattr_init()

int pthread_mutexattr_setprioceiling (pthread_mutexattr_t * attr, int prioceiling);

Устанавливает и возвращает атрибут предельного приоритета мьютекса, заданного параметром attr. Параметр prioceiling содержит значение предельного приоритета мьютекса. Атрибут prioceiling определяет минимальный уровень приоритета, при котором еще выполняется критический раздел, защищаемый мьютексом. Значения, которые попадают в этот диапазон приоритетов, определяются стратегией планирования SCHED_FIFO

int pthread_mutexattr_getprioceiling (const pthread_mutexattr_t * restrict attr, int *restrict prioceiling);

int pthread_mutexattr_setprotocol (pthread_mutexattr_t * attr, protocol int protocol);

Устанавливает и возвращает атрибут протокола мьютекса, заданного параметром attr. Параметр protocol может содержать следующие значения: PTHREAD_PRIO_NONE (на приоритет и стратегию планирования потока владение мьютексом не оказывает влияния);

int pthread_mutexattr_getprotocol (const pthread_mutexattr_t * restrict attr, int *restrict protocol);

PTHREAD_PRIO_INHERIT (при таком протоколе поток, блокирующий другие потоки с более высокими приоритетами, благодаря владению таким мьютексом будет выполняться с самым высоким приоритетом из приоритетов потоков, ожидающих освобождения любого из мьютексов, которыми владеет данный поток);

PTHREAD_PRIO_PROTECT (при таком протоколе потоки, владеющие таким мьютексом, будут выполняться при наивысших предельных значениях приоритетов всех мьютексов, которыми владеют эти потоки, независимо оттого, заблокированы ли другие потоки по каким-то из этих мьютексов)

int pthread_mutexattr_setpshared (pthread_mutexattr_t * attr, int pshared);

Устанавливает и возвращает атрибут process-shared мьютексного атрибутного объекта, заданного параметром attr. Параметр pshared может содержать следующие значения:

int pthread_mutexattr_getpshared (const pthread_mutexattr_t * restrict attr, int *restrict pshared);

PTHREAD_PROCESS_SHARED (разрешает разделять мьютекс с любыми потоками, которые имеют доступ к выделенной для этого мьютекса памяти, даже если эти потоки принадлежат различным процессам);

PTHREAD_PROCESS_PRIVATE

(мьютекс разделяется между потоками одного и того же процесса)

int pthread_mutexattr_settype (pthread_mutexattr_t* attr, int type);

Устанавливает и возвращает атрибут мьютекса type мьютексного атрибутного объекта, заданного параметром attr. Атрибут мьютекса type позволяет определить, будет ли мьютекс распознавать взаимоблокировку, проверять ошибки и т.д. Параметр type может содержать такие значения:

int

PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_RECURSIVE PTHREAD_MUTEX_ERRORCHECK PTHREAD_MUTEX_NORMAL

pthread_mutexattr_gettype (const pthread_mutexattr_t * restrict attr, int *restrict type);

Самый большой интерес представляет установка атрибута, связанного с тем, каким должен быть мьютекс: закрытым или разделяемым. Закрытые мьютексы разделяются между потоками одного процесса. Можно либо объявить мьютекс глобальным, либо организовать передачу дескриптора между потоками. Разделяемые мьютексы используются потоками, имеющими доступ к памяти, в которой разме щ ен данный мьютекс. Такой мьютекс могут разделять потоки различных процессов. Принцип действия закрытого и разделяемого мьютексов показан на рис. 5.5. Если разделять мьютекс приходится потокам различных процессов, его необходимо разместить в памяти, которая является общей для этих процессов. В библиотеке POSIX определено несколько функций, предназначенных для распределения памяти между объектами с помощью отображаемых в памяти файлов и объектов разделяемой памяти. В процессах мьютексы можно использовать для защиты критических разделов, которые получают доступ к файлам, каналам, общей памяти и внешним устройствам.

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

Мьютексы используются для управления критическими разделами процессов и потоков, чтобы предотвратить возникновение условий «гонок». Мьютексы позволяют избежать условий «гонок», реализуя последовательный доступ к критическому разделу. Рассмотрим код листинга5.1. В нем демонстрируется выполнение двух потоков. Для защиты их критических разделов и используются мьютексы.

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

// критических разделов потоков

// . . .

pthread_t ThreadA, ThreadB; pthread_mutex_t Mutex,-pthread_mutexattr_t MutexAttr;

void *task1(void *X) {

pthread_mutex_lock(&Mutex); // Критический раздел кода.

pthread_mutex_unlock(&Mutex);

return(0) ;

}

void *task2 (void *X) {

pthread_mutex_lock(&Mutex) ;

// Критический раздел кода.

pthread_mutex_unlосk (&Mu t ex) ; return(0) ;

}

int main(void) {

//...

pthread_mutexattr_init (&MutexAttr) ;

pthread_mutex_init (&Mutex, &MutexAttr) ;

//Устанавливаем атрибуты мьютекса.

pthread_create(&ThreadA, NULL, taskl, NULL) ; pthread_create(&ThreadB,NULL, task2,NULL) ;

//...

return(0) ;

}

В листинге 5.1 потоки ThreadA и ThreadB содержат критические разделы, защищаемые с помощью объекта Mutex.

В листинге 5.2 демонстрируется, как можно использовать мьютексы для защиты критических разделов процессов.

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

// критических разделов процессов

//...

int Rt;

pthread_mutex_t Mutexl ; pthread_mutexattr_t MutexAttr;

int main(void) {

//...

pthread_mutexattr_init (&MutexAttr); pthread_mutexattr_setpshared(

&MutexAttr,

PTHREAD_PROCESS_SHARED ) ;

pthread_mutex_init (&Mutexl, &MutexAttr) ; if((Rt = fork()) == 0){

// Сыновний процесс.

pthread_mutex_lock(&Mutexl);

// Критический раздел.

pthread_mutex_unlock(&Mutexl) ;

}

else{

// Родительский процесс,

pthread_mutex_lock(&Mutexl); // Критический раздел. pthread_mutex_unlock(&Mutexl) ;

}

//.. .

return(0);

}

Рис. 5.5. Закрытые и разделяемые мьютексы

Важно отметить, что в листинге 5.2 при вызове следующей функции мьютекс инициализируется как разделяемый:

pthread_mutexattr_setpshared(&MutexAttr,PTHREAD_PROCESS_SHARED);

Установка этого атрибута равным значению PTHREAD_PROCESS_SHARED позволяет объекту Mutex стать разделяемым между потоками различных процессов. После вызова функции fork () сыновний и родительский процессы могут защищать свои критические разделы с помощью объекта Mutex. Критические разделы этих процессов могут содержать некоторые ресурсы, разделяемые обоими процессами.

Блокировки для чтения и записи

Мьютексные семафоры позволяют управлять критическими разделами, обеспечивая последовательный вход в эти разделы. В любой момент времени вход в критический раздел разрешается только одному потоку или процессу. Реализуя блокировки для чтения и записи, можно разрешить вход в критический раздел сразу нескольким потокам, если они намерены лишь считывать данные из разделяемой памяти. Следовательно, блокировкой для чтения может владеть любое количество потоков. Но если сразу несколько потоков должны записывать или модифицировать данные общей памяти, то доступ для этого будет предоставлен только одному потоку. Другими словами, никаким другим потокам не будет разрешено входить в критический раздел, если одному потоку предоставлен монопольный доступ для записи в разделяемую память. Такой подход может оказаться полезным, если приложения чаще считывают данные, чем записывают их. Если в приложении создается множество потоков, организация взаимно исключающего доступа может оказаться излишней предосторож н остью. Производительность такого приложения может значительно увеличиться, если в не м разрешить одновре м енное считывание данных нескольки м и потока м и. Стандарт POSIX определяет м еханиз м блокировки для чтения и записи посредство м типа pthread_rwlock_t.

Блокировки для чтения и записи и м еют такие же операции, как и м ьютексные семафоры. Они перечислены в табл. 5.4.

Различие между обычными мьютексами и мьютексами, обеспечивающими чтение и запись, заключается в операциях запроса на блокирование. Вместо одной операции блокирования здесь предусмотрено две:

pthread_rwlock_rdlock()

pthread_rwlock_wrlock ()

Функция pthread_rwlock_rdlock() предоставляет вызываю щ ему потоку блокировку чтения, а функция pthread_rwlock_wrlock() — блокировку записи. Запросив блокировку чтения, поток получит ее в том случае, если нет потоков, удерживающих блокировку записи. Если же таковые имеются, вызывающий поток блокируется. Если поток запросит блокировку записи, он ее получит в том случае, если нет потоков, удерживающих блокировку чтения или блокировку записи. Если же таковые имеются, вызывающий поток блокируется.

Блокировка чтения-записи реализуется с помощью объектов типа pthread_rwlock_t. Этот же тип имеет атрибутный объект, который инкапсулирует атрибуты объекта блокировки. Функции установки и чтения атрибутов перечислены в табл. 5.5.

Объект типа pthread_rwlock_t может быть закрытым (для разделения между потоками одного процесса) или разделяемым (для разде л ения между потоками различных процессов).

Таблица 5.4. Операции, используемые для блокировки ч т ения-записи

Операции

Инициализация

• int pthread_rwlock_init(pthread_rwlock_t *restrict rwlock, const pthread_rwlockattr_t *restrict attr);

Запрос на блокировку

• int pthread_rwlock_rdlock(pthread_rwlock_t *rwlock);

• int pthread_rwlock_wrlock(pthread_rwlock_t *rwlock);

• int pthread_rwlock_timedrdlock(pthread_rwlock_t *restrict rwlock, const struct timespec *restrict abs_timeout);

• int pthread_rwlock_timedwrlock( pthread_rwlock_t | *restrict rwlock, const struct timespec *restrict abs_timeout);

Освобождение блокировки

• int pthread_rwlock_unlock(pthread_rwlock_t *rwlock);

Тестирование блокировки

• int pthread_rwlock_tryrdlock(pthread_rwlock_t *rwlock);

• int pthread_rwlock_trywrlock(pthread_rwlock_t *rwlock);

Разрушение

• int pthread_rwlock_destroy(pthread_rwlock_t *rwlock);

Таблица 5.5. Функции доступа к атрибутному объекту типа pthread_rwlock_t

• int pthread_rwlockattr_init (pthread_rwlockattr_t * attr);  Инициализирует атрибутный объект блокировки чтения-записи,заданный параметром attr , значениями, действующими по умолчанию для всех атрибутов, определенных реализацией

• int pthread_rwlockattr_destroy (pthread_rwlockattr_t * attr) Разрушает атрибутный объект б л окировки чтения-записи,заданный параметром attr Его можно инициализировать повторно, вызвав функцию pthread_rwlockattr_init ()

• int pthread_rwlockattr_setpshared (pthread_rwlockattr_t * attr, int pshared); int pthread_rwlockattr_getpshared (const pthread_rwlockattr_t * restrict attr, int *restrict pshared); Устанавливает или возвращает атрибут process-shared атрибутного объекта блокировки чтения-записи, заданного параметром attr . Параметр pshared может содержать следующие значения:

• PTHREAD_PROCESS_SHARED (разрешает б л окировку чтения-записи, разделяемую любыми потоками, которые имеют доступ к памяти, выделенной для этого объекта блокировки, даже если потоки принадлежат различным процессам);

• PTHREAD_PROCESS_PRIVATE (блокировка чтения-записи разделяется между потоками одного процесса)

Использование блокировок чтения-записи для реализации стратегии доступа

Блокировки чтения-записи можно использовать для реализации стратегии доступа CREW (параллельное чтение и исключающая запись). Согласно этой стратегии возможность параллельно считывать данные может быть предоставлена сразу нескольким задачам, но только одна задача получит право доступа для записи. При выполнении монопольной записи в этом случае не будет дано разрешение на параллельное чтение данных. Использование блокировок чтения-записи для защиты критических разделов продемонстрировано в листинге 5.3.

// Листинг 5.3. Пример использования потоками блокировок

// чтения-записи

//...

pthread_t ThreadA, ThreadB, ThreadC, ThreadD ; pthread_rwlock_t RWLock;

void *producerl(void *X) {

pthread_rwlock_wrlock(&RWLock) ; // Критический раэдел.

pthread_rwlock_unlock(&RWLock) ; return(0);

}

void *producer2 (void *X) {

pthread_rwlock_wrlock(&RWLock) ; // Критический раздел.

pthread_rwlock_unlock(&RWLock) ;

}

void *consumerl(void *X) {

pthread_rwlock_rdlock(&RWLock); // Критический раздел.

pthread_rwlock_unlock(&RWLock); return(0);

}

void *consumer2(void *X) {

pthread_rwlock_rdlock(&RWLock); // Критический раздел.

pthread_rwlock__unlock(&RWLock); return(0);

}

int main(void) {

pthread_rwlock_init(&RWLock,NULL); // Устанавливаем атрибуты мьютекса. pthread_create(&ThreadA, NULL, producerl, NULL) pthread_create(&ThreadB, NULL, consumerl, NULL) pthread_create(&ThreadC,NULL,producer2,NULL) pthread_create(&ThreadD,NULL, consumer2,NULL) //.. .

return(0);

}

В листинге 5.3 создаются четыре потока. Два потока, ThreadA и ThreadC, выполняют роль изготовителей, а остальные два (ThreadB и ThreadD) — потребителей. Все потоки имеют критический раздел, который защищается объектом блокировки чтения-записи RWLock. Потоки ThreadB и ThreadD могут входить в свои критические разделы параллельно или последовательно, но это исключено, если поток ThreadA или ThreadC пребывает в своем критическом разделе. Потоки ThreadA и ThreadC не могут входить в свои критические разделы параллельно. Частичная таблица решении для листинга 5.3 показана в табл. 5.6.

Таблица 5.6. Час т ич н ая таблица решений для листинга 5.3

Поток А

Поток В

Поток С

Поток D

(выполняет запись)

(выполняет чтение)

(выполняет запись)

(выполняет чтение)

Нет

Нет

Нет

Да

Нет

Нет

Да

Нет

Нет

Да

Нет

Нет

Нет

Да

Нет

Да

Да

Нет

Нет

Нет

Условные переменные

Условная переменная представляет собой семафор, используемый для сигнализации о событии, которое произошло. Сигнала о том, что произошло некоторое событие, может ожидать один или несколько процессов (или потоков) от других процессов или потоков. Следует понимать различие между условными переменными и рассмотренными выше мьютексными семафорами. Назначение мьютексного семафора и блокировок чтения-записи — синхронизировать доступ к данным, в то время как условные переменные обычно используются для синхронизации последовательности операций. По этому поводу в своей книге UNIX Network Programming прекрасно высказался Ричард Стивенс (W. Richard Stevens): « Мьютексы нужно использовать для блокирования, а не для ожидания ».

В листинге 4.6 поток-«потребитель» содержал цикл:

15 while(TextFiles.empty())

16 {}

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

Условная переменная имеет тип pthread_cond_t. Ниже перечислены типы операций, которые может она выполнять:

• инициализация;

• разрушение;

• ожидание;

• ожидание с ограничением по времени;

• адресная сигнализация;

• всеобщая сигнализация;

Операции инициализации и разрушения выполняются условными переменными подобно аналогичным операциям других мьютексов. Функции класса pthread_cond_t, которые реализуют эти операции, перечислены в табл. 5.7.

Ожидание

int pthread_cond_wait(pthread_cond_t * restrict cond, pthread_mutex_t *restrict mutex);

int pthread_cond_timedwait( pthread_cond_t * restrict cond, pthread_mutex_t *restrict mutex, const struct timespec *restrict abstime);

Сигнализация

int pthread_cond_signal(pthread_cond_t*cond);

int pthread_cond_broadcast( pthread_cond_t *cond);

Разрушение

int pthread_cond_destroy(pthread_cond_t*cond);

Инициализация

int pthread_cond_init(pthread_cond_t *restrict cond, const pthread_condattr_t *restrict attr);

pthread_cond_t cond =PTHREAD_C OND_INITIALIZER;

Таблица 5.7. Функции класса pthread_cond_t, которые реализуют операции условных переменных

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

//. . .

pthread_mutex_lock(&Mutex) ;

pthread_cond_wait(&EventMutex, &Mutex);

//. . .

pthread_mutex_unlock(&Mutex) ;

Итак, некоторая задача делает попытку заблокировать мьютекс. Если мьютекс уже заблокирован, то эта задача блокируется. После разблокирования задача освободит мьютекс Mutex и при этом будет ожидать сигнала для условной переменной EventMutex . Если мьютекс не заблокирован, задача будет ожидать сигнала неограниченно долго. При ожидании с ограничением по времени задача будет ожидать сигнала в течение заданного интервала времени. Если это время истечет до получения задачей сигнала, функция возвратит код ошибки. Затем задача вновь затребует мьютекс.

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

Условная переменная также имеет атрибутный объект, функции которого перечислены в табл. 5.8.

Таблица 5.8. Функции доступа к атрибутному объекту для условной переменной типа pthread_cond_t

• int pthread_condattr_init ( pthread_condattr_t * attr) Инициализирует атрибутный объект условной переменной, заданный параметром attr, значениями, действующими по умолчанию для всех атрибутов, определенных реализацией;

• int pthread_condattr_destroy ( pthread_condattr_t * attr) ; Разрушает атрибутный объект условной переменной, заданный параметром attr. Этот объект можно инициализировать повторно, вы-звав функцию pthread_condattr_init ()

• int pthread_condattr_setpshared ( pthread_condattr_t * attr,int pshared);

• int pthread_condattr_getpshared ( const pthread_condattr_t * restrict attr, int *restrict pshared); Устанавливает или возвращает атрибут process-shared атрибутного объекта условной переменной, заданного параметром attr. Параметр pshared может содержать следующие значения:

• PTHREAD_PROCESS_SHARED (разрешает блокировку чтения-записи, разделяемую любыми потоками, которые имеют доступ к памяти, выделенной для этой условной переменной, даже если потоки принадлежат различным процессам);

• PTHREAD_PROCESS_PRIVATE (Условная Переменная разделяется между потоками одного процесса)

• int pthread_condattr_setclock ( pthread_condattr_t * attr, clockid_t clock_id);

• int pthread_condattr_getclock ( const pthread_condattr_t * restrict attr, clockid_t * restrict clock_id); Устанавливает или возвращает атрибут clock атрибутного объекта условной переменной, заданного параметром attr . Атрибут clock представляет собой идентификатор часов, используемых для измерения лимита времени в функции pthread_cond_timedwait (). По умолчанию для атрибута clock используется идентификатор системных часов

Использование условных переменных для управления отношениями синхронизации

Условную переменную можно использовать для реализации отношений синхронизации, о которых упоминалось выше: старт-старт (CC), финиш-старт (ФС), старт-финиш (СФ) и финиш-финиш (ФФ). Эти отношения могут существовать между потоками одного или различных процессов. В листингах 5.4 и 5.5 представлены примеры реализации ФС- и ФФ-отношений синхронизации. В каждом примере определено два мьютекса. Один мьютекс используется для синхронизации доступа к общим данным, а другой — для синхронизации выполнения кода.

// Листинг 5.4. ФС-отношения синхронизации между

// двумя потоками

//. . .

float Number;

pthread_t ThreadA,ThreadB;

pthread_mutex_t Mutex, EventMutex;

pthread_cond_t Event;

void * worker1 (void *X) {

for(int Count = l;Count < 100;Count++){

pthread_mutex_lock(&Mutex);

Number++;

pthread_mutex_unlock(&Mutex);

cout << «worker1: число равно» << Number << endl;

if(Number == 50){

pthread_cond_signal(&Event);

}

}

cout << «Выполнение функиии worker1 завершено.» << endl;

return(0);

}

void * worker2 (void *X) {

pthread_mutex_lock(&EventMutex);

pthread_cond_wait(&Event,&EventMutex);

pthread_mutex_unlock(&EventMutex);

for(int Count = 1;Count < 50;Count++){

pthread_mutex_lock(&Mutex);

Number = Number + 20;

pthread_mutex_unlock(&Mutex);

cout << «worker2: число равно» << Number << endl;

}

cout « «Выполнение функции worker2 завершено.» « endl; return(0);

};

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

pthread_mutex_init(&Mutex,NULL);

pthread_mutex_init(&EventMutex,NULL);

pthread_cond_init(&Event, NULL);

pthread_create(&ThreadA, NULL, workerl, NULL);

pthread_create(&ThreadB, NULL, worker2 , NULL);

//. . .

return (0);

}

В листинге 5.4 показан пример реализации ФС-отношений синхронизации. Поток ThreadA не может завершиться до тех пор, пока не стартует поток ThreadB. Если значение переменной Number станет равным 50, поток ThreadA сигнализирует о этом потоку ThreadB. Теперь он может продолжать выполнение до самого конца Поток ThreadB не может начать выполнение до тех пор, пока не получит сигнал от потока ThreadA. Поток ThreadB использует объект EventMutex вместе с условной переменной Event. Объект Mutex используется для синхронизации доступа для записи значения разделяемой переменной Number. Для синхронизации различных событий и доступа к критическим разделам задача может использовать несколько мьютексов.

Пример реализации ФФ-отношений синхронизации показан в листинге 5.5.

// Листинг 5.5. ФФ-отношения синхронизации между // двумя потоками

//...

float Number;

pthread_t ThreadA, ThreadB ;

pthread_mutex_t Mutex, EventMutex;

pthread_cond_t Event;

void *workerl(void *X) {

for(int Count = l;Count < 10;Count++){

pthread_mu tex_l ock (&Mutex);

Number++;

pthread_mutex_unlосk(&Mutex);

cout « «workerl: число равно " << Number « endl;

}

pthread_mutex_lock(&EventMutex) ,-

cout « «Функция workerl в состоянии ожидания. " « endl;

pthread_cond_wait (&Event, &EventMutex) ;

pthread_mutex_unlock(&EventMutex);

return(0);

}

void *worker2 (void *X) {

for(int Count = l;Count < 100;Count++){

pthread_mutex_lock(&Mutex) ;

Number = Number * 2 ;

pthread_mutex_unlock(&Mutex) ;

cout « «worker2: число равно " « Number « endl;

}

pthread_cond_signal (&Event) ;

cout « «Функция worker2 послала сигнал " « endl; return(0);

}

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

pthread_mutex_init (&Mutex,NULL) ;

pthread_mutex_init (&EventMutex,NULL) ;

pthread_cond_init (&Event, NULL) ;

pthread_create(&ThreadA, NULL,workerl, NULL);

pthread_create (&ThreadB, NULL, worker2, NULL) ;

//.. .

return (0);

}

В листинге 5.5 поток ThreadA не может завершиться до тех пор, пока не завершится поток ThreadB. Поток ThreadA должен выполнить цикл 10 раз, а ThreadB — 100. Поток ThreadA завершит выполнение своих итераций раньше ThreadB, но будет ожидать до тех пор, пока поток ThreadB не просигналит о своем завершении.

CC- и СФ-отношения синхронизации невозможно реализовать подобным образом. Эти методы используются для синхронизации пор я дка выполнени я процессов.

Объектно-ориентированный подход к синхронизации

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

Для реализации такого подхода данные многопоточного приложения (по возможности) необходимо инкапсулировать с помощью С++-конструкций class или struct. Затем инкапсулируйте такие механизмы синхронизации, как семафоры, блокировки для обеспечения чтения-записи и мьютексы событий. Если данные или механизмы синхронизации представляют собой объекты, создайте для них интерфейсный класс. Наконец, объедините объект данных с объектами синхронизации посредством наследования или композиции, чтобы создать объекты данных, которые будут безопасны для потоков. Этот подход подробно рассматривается в главе 11.

Резюме

Для координации порядка выполнения процессов и потоков (синхронизация задач), а также доступа к разделяемым данным (синхронизация данных) можно использовать различные механизмы синхронизации. Су щ ествует четыре основных вида отношений синхронизации задач. Отношение вида «старт-старт» (CC) означает, что задача А не может начаться до тех пор, пока не начнется задача В. Отношение вида «финиш-старт» (ФС) означает, что задача А не может завершиться до тех пор, пока не начнется задача В. Отношение вида «старт-финиш» (СФ) означает, что задача А не может начаться до тех пор, пока не завершится задача В. Отношение вида «финиш-финиш» (ФФ) означает, что задачаА не может завершиться до тех пор, пока не завершится задача В. Для реализации этих отношений синхронизации задач можно использовать условную переменную pthread_cond_t, которая определена стандартом POSIX.

Для описания синхронизации данных используются некоторые типы алгоритмов модели PRAM. Стратегию доступа EREW (исключающее чтение и исключающая запись) можно реализовать с помощью мьютексного семафора. Мьютексный семафор защищает критический раздел, обеспечивал последовательный вход в него. Эта стратегия разрешает либо доступ для чтения, либо доступ для записи. Стандарт POSIX определяет мьютексный семафор типа pthread_mutex_t , который можно использовать для реализации стратегии доступа EREW. Чтобы реализовать стратегию доступа CREW (параллельное чтение и исключающая запись), можно использовать блокировки чтения-записи. Стратегия доступа CREW описывает возможность удовлетворения множества запросов на чтение, но при монопольной записи данных. Стандарт POSIX определяет объект блокировки для обеспечения чтения-записи типа pthread_rwlock_t , а объектно-ориентированный подход к синхронизации данных позволяет встроить механизм синхронизации в объект данных.

Объединение возможностей параллельного программирования и C++ средств на основе PVM

Мы разделили нашу проблему на две части: сгенерированную программу и процесс обучения. Эти две части остаются тесно связанными. Нельзя ожидать, что сгенерированная машина окажется удачной с первой же попытки. Необходимо поэкспериментировать с обучением одной такой машины и посмотреть, как пойдет этот процесс обучения...

Алан Тьюринг (Alan Turing), Может ли машина думать?

Система програм м ного обеспечения PVM (Parallel Virtual Machine — параллельная виртуальная м ашина) предоставляет разработчику ПО средства для написания и выполнения программ, использующих параллелизм. Система PVM позволяет разработчику представить коллекцию сетевых компьютеров в виде единой логической машины с возможностями параллелизма. Компьютеры этой коллекции могут иметь одинаковые или различные архитектуры. В PVM-систему связываются даже компьютеры, которые попадают в категорию MPP (Massively Parallel Processor — процессор с массовым параллелизмом). Несмотря на то что PVM-программы могут разрабатываться для одного компьютера, реальные преимущества этой системы проявляются при связывании двух и более компьютеров.

6.1. Классические модели параллелизма, поддерживаемые системой PVM

Система PVM в качестве средства связи между параллельно выполняющимися задачами поддерживает модель передачи сообщений. Приложение взаимодействует с PVM посредством библиотеки, которая состоит из API-интерфейсов, предназначенных для управления процессами, отправки и получения сообщений, сигнализации процессов и т.д. С++-программа взаимодействует с PVM-библиотекой точно так же, как с любыми другими библиотеками функций. С++-программе для получения доступа к функциям РVM-библиотеки не нужно создавать специальную форму или архитектуру,в то врем я как программам, написанным на других я зыках, необходимо вызывать определенные функции для инициализации среды. Это означает, что С++-программист может сочетать PVM-возможности с другими стилями С++-программирования (например, объектно-ориентированным, параметризованным, агентно-ориентированным и структурированным программированием). Благодаря использованию таких библиотек, как PVM, MPI или Linda, С++-разработчик может реализовать различные модели параллелизма, тогда как другие языки ограничены примитивами параллелизма, которые встроены в сами языки. Библиотека PVM предлагает, пожалуй, самый простой способ расширения средств языка С++ за счет возможностей параллельного программирования.

Классические модели параллелизма, поддерживаемые системой PVM

Система PVM поддерживает модели MIMD (Multiple-Instruction, Multiple-Data— множество потоков команд, множество потоков данных) и SPMD (Single-Program, Multiple-Data — одна программа, множество потоков данных) параллелизма. В действительности SPMD — это вариант модели SIMD (Single-Instruction, Multiple-Data — один поток команд, множество потоков данных). Эти модели разбивают программы на потоки команд и данных. В модели MIMD программа состоит из нескольких параллельно выполняющихся потоков команд, причем каждому из них соответствует собственный локальный поток данных. По сути, каждый процессор здесь имеет собственную память. В PVM-среде модель MIMD считается моделью с распределенной памятью (в отличие от модели с общей памятью). В моделях с общей памятью все процессоры «видят» одни и те же ячейки памяти. В модели с распределенной памятью связь между хранимыми в ней значениями обеспечивается посредством механизма передачи сообщений. Однако модель SPMD подразумевает наличие одной программы (одного набора команд), которая параллельно выполняется на нескольких компьютерах, причем эти одинаковые на всех машинах программы обрабатывают различные потоки данных. PVM-среда поддерживает как MIMD-, так и SIMD-модели или их сочетание. Четыре классические модели параллелизма показаны на рис. 6.1.

Обратите внимание на то, что модели SISD и MISD (см. рис.6.1) неприменимы к системе PVM. Модель SISD описывает однопроцессорную машину, а для модели MISD вооб щ е трудно найти практическое применение. Две остальные модели, которые можно использовать с системой PVM, определяют, как С++-программа взаимодействует с компьютерами. Разработчик ПО представляет один логический виртуальный компьютер как среду для выполнения нескольких различных параллельных задач, каждая из которых получает доступ к собственным данным, либо одной задачи, выполняющейся в виде набора параллельных клонов, получаю щ их доступ к различным областям данных. Таким образом, с PVM-задачами мы будет связывать только модели, предполагаю щ ие наличие множества потоков команд и одной програм м ы.

Библиотека PVM для языка С++

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

• Управление процессами.

• Упаковка сооб щ ений и их отправка.

• Распаковка сооб щ ений и их прием.

• Обмен задач сигналами.

• Управление буферо м сооб щ ений.

• Функции обработки инфор м ации и служебные процедуры.

• Групповые операции.

Эти библиотечные функции легко интегрировать в С++ среду. Префикс pvm_ в имени каждой функции позволяет не забыть о ее принадлежности соответствующему пространству имен. Для использования PVM-функций необходимо включить в программу заголовочный файл pvm3 . h и скомпоновать ее с библиотекой libpvm. В программах 6.1 и 6.2 демонстрируется, как работает простая PVM-программа. Инструкции по компиляции и выполнению программы 6.1 приведены в разделе «Профиль програ мм ы 6.1».

// Программа 6.1

#include «pvm3.h» #include <iostream> #include <string.h>

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

int RetCode,MessageId;

int PTid, Tid;

char Message[100j;

float Result[l];

PTid = pvm_mytid();

RetCode = pvm_spawn(«program6-2»,NULL,0,''",l,&Tid);

if(RetCode == 1){

MessageId = 1;

strcpy(Message,«22»);

pvm_initsend(PvmDataDefault);

pvm_pkstr(Message);

pvm_send(Tid,MessageId);

pvm_recv(Tid,MessageId);

pvm_upkfloat(Result,1,1);

cout « Result[0] « endl;

pvm_exit();

return(0) ;

}

else{

cerr << «Задачу породить невозможно. " « endl;

pvm_exit();

return(1) ;

}

}

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

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

Описание |Использует функцию pvn_send{) для пересылки числа в другую PVM-задачу, которая выполняется параллельно с данной (программа6.2), и функцию pvm_recv() для получения числа от этой задачи.

Требуемая библиотека libpvm3

Требуемые заголовки <pvm3.h> <iostream> <string.h>

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

gcс++ -о program6-l -I $PVM_ROOT/include -L $PVM_ROOT/lib/ | SPVM_ARCH -1 pvm3

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

Solaris8,PVM 3.4.3, SuSE Linux 7.1, gcc 2.95.2.

Инструкции по выполнению ./program6-l

Примеча н ия Необходимо запустить на выполнение программу pvmd.

В програм м е 6.1 использовано восе м ь са м ых распространенных PVM-функций: pvm_mytid(), pvm_spawn(), pvm_initsend(), pvm_pkstr(), pvm_send (), pvm_recv (), pvm_upkfloat () и pvm_exit (). Функция pvm_mytid () возвращает идентификатор вызываю щ его процесса (задачи). PVM-систе м а связывает идентификатор задачи с кажды м процессо м, который ее создает. Идентификатор задачи ис пользуется для отправки сооб щ ений задача м, получения сооб щ ений от других задач, сигнализации, прерывания задач и т.п. Любая PVM-задача м ожет связываться с любой другой PVM-задачей до тех пор, пока не получит доступ к ее идентификатору. Функция pvm_spawn( ) предназначена для запуска нового PVM-процесса. В программе 6.1 функция pvm_spawn () используется для запуска на выполнение программы 6.2. Идентификатор новой задачи возвра щ ается в параметре &Tid вызова функции pvm_spawn (). В PVM-среде для передачи данных между задачами используются буфе ры сооб щ ений. Каждая задача может иметь один или несколько таких буферов. При этом только один из них считается активным. Перед отправкой каждого сооб щ ения вызывается функция pvm_initsend() , которая позволяет подготовить или инициа л изировать активный буфер сообщений. Функция pvm_pkstr () используется для упаковки строки, содержащейся в пара м етре Message. При упаковке строка шифруется для передачи другой за д аче (в другой процесс), выполняе м ой, воз м ожно, на друго м компьютере с другой архитектурой. PVM-среда обрабатывает элементы, связанные с преобразованием из одной архитектуры в другую. Среда PVM требует применять процедуру упаковки сооб щ ения до его отправки и проце д уру распаковки при его получении, чтобы с д елать сооб щ ение читабельным д ля получателя. О д нако из этого правила су щ ествует исключение, которое мы обсу д им ниже. Функции pvm_send() и pvm_recv() используются для отправки и приема сообщений соответственно. Параметр MessageId просто опре д еляет, с каким сооб щ ением работает отправитель. Обратите внимание на то, что в программе 6.1 функции pvm_send( ) и pvm_recv( ) со д ержат и д ентификатор за д ачи, получаю щ ей д анные, и и д ентификатор за д ачи, отправляю щ ей данные, соответственно. Функция pvm_upkfloat() извлекает полученное сооб щ ение из активного буфера сооб щ ений и распаковывает его, сохраняя в массиве типа float. Программа 6 порождает PVM-задачу для выполнения программы 6.2.

Обратите внимание на то, что обе программы 6.1 и 6.2 содержат обра щ ение к функ ции pvm_exit (). Эту функцию необходимо вызывать при завершении PVM обработки задачи. Несмотря на то что функция pvm_exit () не разрушает процесс и не прекращает его выполнение, она позволяет PVM-среде освободиться от задачи и отсоединить за дачу от PVM-среды. Обратите внимание на то, что программы 6.1 и 6.2 — вполне авто номные и независимые програ мм ные модули , которые содержат функцию main (). Де тали реализации програ мм ы 6.2 приведены в разделе «Профиль програ мм ы 6.2».

// Программа 6.2

#include «pvm3.h» #include «stdlib.h»

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

int MessageId, Ptid;

char Message[100];

float Num,Result,-Ptid = pvm_parent();

MessageId = 1;

pvm_recv(Ptid,MessageId) ;

pvm_upkstr(Message) ; Num = atof(Message); Result = Num / 7.0001r pvm_initsend(PvmDataDefault); pvm_pkfloat(&Result,1,1); pvm_send(Ptid,MessageId); pvm_exit(); return(0);

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

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

Описание Эта программа принимает число от родительского процесса и делит его на 7. Затем она отправляет результат своему родительскому процессу.

Требуемая библиотека libpvm3 . .

Требуемые заголовки < pvm3.h> <stdlib.h>

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

ф^У--о-^годгат6-2 -I $PVM_ROOT/include program6~2.cc -L : /^^_RCX)T/lib/PVM_ARCH -lpvm3

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

|fiuJJE Onux 7.1 gnu С++ 2.95.2, Solaris 8 Workshop 6, PVM 3.4.3. У4нструкции по выполнению Эта программа порождается программой 6.1. |Примечания

Необходимо запустить на выпол н ение программу pvmd.

Компиляция и компоновка C++/PVM-npoгpaмм

Версия 3.4.x PVM-среды представлена в виде единой библиотеки libpvm3 . а. Чтобы скомпилировать PVM-программу, необходимо включить в ее код заголовочный файл pvm3.h и скомпоновать ее вместе с библиотекой libpvm3.а :

$ с++ -о mypvm_program -I $PVM_ROOT/include program.cc -L$PVM_ROOT/lib -lpvm3

Переменная среды $PVM_ROOT указывает на каталог, в котором инсталлирована библиотека PVM. При выполнении этой команды создается двоичный файл mypvm_program.

Для выполнения программ 6.1 и 6.2 сначала необходимо инсталлировать PVM-среду. Выполнить PVM-программу можно одним из трех основных способов: запустить автономный выполняемый (двоичный) файл, использовать PVM-консоль или среду XPVM.

Выполнение PVM-программы в виде двоичного файла

Во-первых, необходимо запустить программу pvmd; во-вторых, на каждом компьютере, включенном в PVM-среду, корректно ско м пилированные программы-участницы должны находиться в соответствую щ их каталогах. По умолчанию для скомпилированных программ (выполняемых файлов) используется такой каталог: $H0ME/pvm3 /bin /$PVM_ARCH

Здесь PVM_ARCH содержит имя архитектуры компьютера (см. табл. 6.1 и параграфы 1 и 2 из раздела6.2.5). Для выполняемых программ должны быть установлены соответствую щ ие разрешения на доступ и использование. ПрограммурллшЭ. можно запустить так: pvmd & или так:

pvmd hostfile &

Здесь hostfile — это файл конфи г урации, содержа щ ий специальные параметры для передачи про г рамме pvmd (см. табл. 6.2 и пара г рафы 1, 2 из раздела6.2.3). После запуска про г раммы pvmd на одном из компьютеров, включенных в среду PVM, можно запустить PVM-программу, используя следующую простую команду: $MyPvmProgram

Если эта программа порождает другие задачи, то они запустятся автоматически.

Запуск PVM-программ c помощью PVM-консоли

Для выполнения программ с помо щ ью PVM-консоли необходимо сначала запустить PVM-консоль, введя следующую команду: $pvm

Получив приглашение на ввод ко м анд pvm>, введите и м я програ мм ы, которую нужно выполнить:

pvm> spawn -> MyPvmProgram

Запуск PVM-программ c помощью XPVM

Кроме PVM-консоли, можно использовать графический интерфейс XPVM для X Windows. На рис. 6.2 показано диалоговое окно сеанса работы с XPVM-интерфейсом.

Библиотека PVM не требует, чтобы С++-программа придерживалась какой -л ибо конкретной структуры. Первая PVM-функци я, вызываема я программой, «поме щ ает» ее в PVM-среду. Дл я каждой программы, которая я вл я ется частью PVM-среды, следует всегда вызывать функцию pvm_exit (). Если этого не сделать, система зависнет.

Практика показывает, что функции pvm_mytid() и pvm_parent () необходи м о вызывать в начале обработки задачи. Наиболее популярные категории функций PVM перечислены в табл. 6.1.

Рис. 6.2. Диалоговое окно графического интерфейса XPVM

Таблица 6.1. Семь категорий фу н кций библио т еки PVM

Категории PVM-функций

Описание

Управление процессами

Упаковка сообщений и их отправка

Распаковка сообщений и их прием

Обмен задач сигналами Управление буфером сообщений

Функции обработки информации и служебные процедуры

Групповые операции

Используются для управления PVM-процесса м и

Применяются для упаковки сооб щ ений в пересылочном буфере и отправки их от одного PVM-процесса другому

Используются для получения сооб щ ений и распаковки данных из активного буфера

Применяются для си г нализации и уведомления PVM-процессов о возникновении события

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

Применяются для получения информации о PVM-процессах и выполнения дру г их важных задач

Используются для объединения процессов в группы и выполнения других групповых операций

Требования к PVM-программам

Если PVM-среда реализуется в виде сети компьютеров, то, прежде чем ваша С++-программа начнет взаимодействовать с ней, необходимо обработать следующие элементы.

Параграф 1

Следует установить переменные среды PVM_ROOT и PVM_ARCH. Переменная среды PVM_ROOT должна указывать на каталог, в котором инсталлирована PVM-б иблиотека.

Использование оболочки Bourne (BASH)

Использование С-оболочки_

$ PVM_ROOT=/usr/lib/pvm3

setenv PVM_ROOT /usr/lib/pvm3

$ export PVM_ROOT

Переменная среды PVM_ARCH идентифицирует архитектуру компьютера. Каждый компьютер, включенный в среду PVM, должен быть идентифицирован архитектурой. Например, Ultrasparcs-компьютеры имеют обозначение SUN4SOL2, а Linux-компьютеры — обозначение LINUX. В табл. 6.2 перечислены самые распространенные архитектуры для PVM-среды.

Эта таблица содержит имя и тип компьютера, соответствую щ ий этому имени. Установите свою переменную среды PVM_ARCH равной одному из имен, приведенных в табл. 6.2. Например:

Использование оболочки Bourne (BASH) _ Использование С-оболочки _

$PVM_ARCH=LIMJX   setenv PVM_ARCH LINUX

$export PVM_ARCH

Таблица 6.2. Самые распростра н енные архитек т уры для PVM-среды

PVM_ARCH

Компьютер

PVM__ARCH

Компьютер

AFX8

Alliance

LINUX

80386/486 PC (UNIX)

ALPHA

DEC Alpha

MASPAR

Maspar

BAL

Sequent Balance

MIPS

MIPS 4680

BFLY

BBN ButterflyTC2000

NEXT

NeXT

BSD386

80386/486 PC (UNIX)

PGON

Intel ParagonIntel Paragon

CM2

«Мыслящая машина» CM2

PMAX

DECstation 3100,5100

CM5

«Мыслящая машина» CM5

RS6K

IBM/RS6000

CNVX

Convex С-серии

RT

IBM RT

CNVXN

Convex С-серии

SGI

Silicon Graphics IRIS

CRAY

C-90, YMP,T3D (доступный

порт) SGI5

Silicon Graphics IRIS

CRAY2

Cray-2

SGIMP

SGI Multiprocessor

CRAYSIMP

CrayS-MP

SUN3

Sun3

6.2. Библио т ека PVM для языка С++ 221

Окончание табл. 6.2

PVM_ARCH

Компьютер

PVM_ARCH

Компьютер

DGAV

Data General Aviion

SUN4

Sun 4, SPARCstation

E88K

Encore 88000

SUN2SOL2

Sun 4, SPARCstation

HP300

НР-9000 Model 300

SUNMP

SPARC Multiprocessor

HPPA

НР-9000 PA-RISC

SYMM

Sequent Symme^

I860

Intel iPSC/860

TITN

Stardent Titan

IPSC2

Intel iPSC/2 386 Host

U370

IBM 370

KSRI

Kendall Square KSR-1

UVAX

DEC LicroVAX

Параграф 2

Выполняемые файлы любых программ, участвующих в среде PVM, должны быть размещены на всех компьютерах, включенных в среду PVM, или доступны всем компьютерам, включенным в среду PVM. При этом каждая программа должна быть скомпилирована для работы с учетом конкретной архитектуры. Это означает, что, если в среду PVM включены процессоры UltraSparcs, PowerPCs и Intel, то мы должны иметь версию программы, скомпилированную для каждой архитектуры. Эту версию программы следует разместить в известном для PVM месте. Таким местом часто служит каталог $HOME /pvm3/bin. Этот каталог может быть также задан в файле конфигурации PVM, который обычно имеет имя hostfile или .xpvm_hosts (если используется среда XPVM). Файл hostfile должен содержать такую запись: ep=/usr/local/pvm3/bin

Эта запись означает, что любые пользовательские выполняемые файлы, необходимые для среды PVM, можно найти в каталоге /usr/local/pvm3 /bin.

Параграф 3

Пользователь, запускаю щ ий PVM-программу, должен иметь сетевой доступ (rsh или ssh) к каждому компьютеру, включенному в среду PVM. По умолчанию PVM получает доступ к каждому компьютеру, используя зарегистрированное имя пользователя, запускаю щ его PVM-программу, или учетную запись компьютера, на котором она запускается. Если потребуется другая учетная запись (помимо зарегистрированного имени пользователя-инициатора), то в файл конфигурации PVM hostfile или .xpvm_hosts необходимо добавить соответствую щ ую запись, например: lo= flashgordon

Параграф 4

Создайте на каждо м компьютере файл .rhosts, в котором перечислите все компьютеры, подлежа щ ие использованию. Эти компьютеры имеют потенциальную возможность для включения в среду PVM. В зависи м ости от содержи м ого файла .xpvm_hosts или файла pvm_hosts, эти компьютеры автоматически будут добавлены в PVM-среду при запуске программы pvmd. Ко м пьютеры, перечисленные в этих файлах, также м огут дина м ически включаться в PVM-среду во вре м я работы.

Параграф 5

Создайте файл $HOME /.xpvm_hosts и/или файл $HOME /pvm_hosts, в котором перечислите все подлежа щ ие использованию ко м пьютеры с приставкой Нал и чие приставки "&" означает неавтоматическое включение компьютера. Без этой приставки компьютер будет включен в PVM-среду автоматически. Файл pvm_hosts создается пользователем и может иметь произвольное имя. Но в среде XPVM необходимо ис пользовать только имя .xpvm_hosts. Пример такого файла показан на рис. 6.3. Аналогичный формат следует использовать для pvm_hosts- или . xpvm_hosts.

Главное внимание необходимо уделить сетевому доступу пользователя, запускаю щ его PVM-программу. Владелец PVM-программы должен иметь доступ к каждому компьютеру, включенному в пул процессоров. Этот доступ будет использовать либо команду rsh, либо rlogin, либо ssh. Выполняемая программа должна быть доступна на каждом компьютере, а PVM-среда должна быть «в курсе» того, какие компьютеры имеются в наличии и где будут инсталлированы выполняемые файлы.

# Строки комментариев начинаются с символа "#"

# (пустые строки игнорируются).

# Строки, начинаю щ иеся с символа "&", позволяют

# включить компьютеры в среду PVM позднее. Если

# имя компьютера не предваряется символом "&",

# этот компьютер включается в среду PVM

# автоматически.

flavius marcus

&cambius lo=romulus &karsius

# Символ означает стандартные опции для

# следую щ их компьютеров

# dx=/export/home/fred/pvm3/lib/pvmd &octavius

# Если компьютеры являются частью типичного

# linux-кластера, то их имена можно использовать

# для включения узлов кластера в среду PVM

#   вместе с другими узлами. _

Объединение динамической С++-библиотеки c библиотекой PVM

Поскольку доступ к PVM-средствам обеспечивается через коллекцию библиотечных функций, С++-программа использует PVM как любую другую библиотеку. Следует иметь в виду, что каждая PVM-програм м а представляет собой автономную C++-программу с собственной функцией main (). Это означает, что все PVM-программы имеют собственное адресное пространство. При порождении каждой PVM-задачи создается ее собственный процесс с новым а д ресным пространством и, соответственно, идентификационный номер процесса. PVM-процессы ви д имы для утилиты ps. Несмотря на то что несколько PVM-задач могут выполняться вместе для решения некоторой пробле м ы, они будут иметь собственные копии динамической C++-библиотеки. Каждая программа имеет собственный поток iostream, библиотеку шаблонов, алгоритмы и пр. В область видимости глобальных С++-пере м енных адресное пространство не попадает. Это означает, что глобальные переменные одной PVM-задачи невидимы для других PVM-задач. Для взаимодействия отдельных задач используется м еханизм передачи сооб щ ений. Этим они отличаются от многопоточных программ, в которых потоки разделяют одно адресное пространство и могут взаимодействовать посредством глобальных переменных и передачи параметров. Если PVM-программы выполняются на одном компьютере с несколькими процессорами, то как дополнительные средства коммуникации программы могут совместно использовать файловую систе м у, каналы, FIFO-очереди и об щ ую па м ять. Несмотря на то что передача сооб щ ений — основной метод взаимодействия между PVM-задачами, ничто не мешает им в качестве дополнительных средств использовать файловую систе м у, буфер об м ена или даже аргументы командной строки. PVM-библиотека не ограничивает, а расширяет возможности динамической С++-библиотеки.

Методы использования PVM-задач

Работу, которую выполняет С++-программа, можно распределить между функциями, объектами или их сочетаниями. Действия, выполняемые программой, обычно делятся на такие логические категории: операции ввода-вывода, интерфейс пользователя, обработка базы данных, обработка сигналов и ошибок, числовые вычисления и т.д. Отделяя код интерфейса пользователя от кода обработки файлов, а также код процедур печати от кода числовых вычислений, мы не только распределяем работу програ м мы между функциями или объектами, но и стараемся выделять категории действий в соответствии с их характером. Логические группы организуются в библиотеки, модули, объектные шаблоны, компоненты и оболочки. Такой тип организации мы поддерживае м и при внесении PVM-задач в С++-програ мм у. Мы може м подойти к деко м позиции работ (work breakdown structure), используя м етод либо восходя щ его, либо нисходя щ его проектирования. В любом случае параллелиз м должен естественно вписываться в работу, которая на м ечена для выполнения функцией, модулем или объектом.

Не самая удачная идея — попытаться директивно навязать параллелиз м програ мм е. Искусственно насаждае м ый параллелиз м является причиной фор м ирования гро м оздкой архитектуры, которая, как правило, трудна для пони м ания и поддержки и создает сложности при определении корректности програ мм ы. Поэто м у, если програ мм а использует PVM-задачи, они должны быть результато м естественного разбиения программы. Каждую PVM-задачу следует отнести к одной из функциональных категорий. Например, если м ы разрабатывае м приложение, которое содержит обработку данных на естественном языке (Natural Language Processing — NLP), м еханиз м речевого воспроизведения текста (text-to-speech engine — TTS-engine) как часть интерфейса пользователя и формирование логических выводов как часть выборки данных, то параллелизм (естественный для NLP-компонента) должен быть представлен в виде задач внутри NLP-модуля или объекта, который отвечает за NLP-обработку. Аналогично параллелизм внутри компонента фор м ирования логических выводов следует представить в виде задач, составляю щ их модуль (объект или оболочку) выборки данных, отвечаю щ ий за выборку данных. Другими словами, мы идентифицируем PVM-задачи там, где они логически вписываются в работу, выполняемую программой, а не просто разбиваем работу программы на набор некоторых об щ их PVM-задач.

Соблюдение первичности логики и вторичности параллелизма имеет несколько последствий для С++-программ. Это означает, что мы могли бы порождать PVM-задачи из функции main () или из функций, вызываемых из функции main () (и даже из других функций). Мы могли бы порождать PVM-задачи из методов, прина д лежащих объектам. Место порождения задач зависит от требований к параллельности, выдвигаемых соответствую щ ей функцией, модулем или объектом. В об щ ем случае PVM-задачи можно разделить на две категории: SPMD (производная от SIMD) и MPMD (производная от MIMD). В модели SPMD все задачи будут выполнять одинаковый набор инструкций, но на различных наборах данных. В модели MPMD все задачи будут выполнять различные наборы инструкций на различных наборах данных. Но какую бы модель мы не использовали (SPMD или MPMD), создание задач должно происходить в соответствую щ их областях программы. Некоторые возможные конфигурации для порождения PVM-задач показаны на рис. 6.4.

Реализация модели SPMD (SIMD) c помощью PVM-и С++-средств

Вариант 1 на рис. 6.4 представляет ситуацию, при которой функция main () порождает от 1 до N задач, причем каждая задача выполняет один и тот же набор инструкций, но на различных наборах данных. Су щ ествует несколько вариантов реализации этого сценария. В листинге 6.1 показана функция main (), которая вызывает функцию pvm_spawn().

// Листинг б.1. Вызов функции pvm_spawn() из // функции main()

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

int TaskId[10]; int TaskId2[5]; // 1-е порождение:

pvm_spawn(«set_combination»,NULL,0,"",10,TaskId);

// 2-е порождение:

pvm_spawn(«set_combination», argv, 0,"",5,TaskId2); //. . .

}

В листинге 6.1 при первом порождении создается 10 задач. Каждал задача будет выполнять один и тот же набор инструкций, содержа щ ихся в программе set_combination. При успешном выполнении функции pvm_spawn () массив TaskId будет содержать идентификаторы PVM-задач. Если про г ра мм а в листин г еб.1 имеет идентификатор TaskIds, то она может использовать функции pvm_send( ) для отправки данных, под г отовленных д л я обработки каждой про г раммой. Это воз м ожно б л а г одаря то м у, что функция pvm_send () содержит идентификатор задачи-получате л я.

Рис. 6.4. Некоторые возможные конфигурации для порождения PVM-задач

При второ м порождении (с м. листин г б.1) создается пять задач, но в это м случае каждой задаче с по м о щ ью пара м етра argv передается необходи м ал информация. Это — дополнительный способ передачи информации задачам при их запуске. Тем самы м сыновние задачи получают е щ е одну воз м ожность уникальны м образо м идентифицировать себя с по м о щ ью значений, получае м ых в пара м етре argv. В листин г е 6 .2, чтобы создать N задач, функция main () несколько раз (вместо одно г о) обра щ ается к функции pvm_spawn ().

// Листинг 6.2. Использование нескольких вызовов

// функции pvm_spawn() из функции main()

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

int Taskl; int Task2; int Task3; //.. .

pvm_spawn(«set_combination», NULL,1,«hostl»,l,&Taskl); pvm_spawn(«sec_combination»,argv,1,«host2»,1, &Task2); pvm_spawn(«set_combination»,argv++,l,«host3»,l,&Task3); //. . .

}

Подход к созданию задач, продемонстрированный в листин г е 6.2, можно использовать в том случае, ко г да нужно, чтобы задачи выполнялись на конкретных компьютерах. В этом состоит одно из достоинств PVM-среды. Ведь про г рамме ино г да стоит воспользоваться преимуществами некоторых конкретных ресурсов конкретно г о компьютера, например, специальным математическим спецпроцессором, процессором графическо г о устройства вывода или какими-то дру г ими возможностями. В листин г е 6.2 обратите внимание на то, что каждый компьютер выпол н яет один и тот же набор инструкций, но все они получили при этом разные ар г ументы командной строки. Вариант 2 (см. рис. 6.4) представляет сценарий, в котором функция main( ) не порождает PVM-задачи. В этом сценарии PVM-задачи ло г ически связаны с функцией funcB (), и поэтому здесь именно функция funcB () порождает PVM-задачи. Функциям main( ) и funcA( ) нет необходимости знать что-либо о PVM-задачах, поэтому им и не нужно иметь соответствую щ ий PVM-код. Вариант 3 (см. рис. 6.4) представл я ет сценарий, в котором функции main () и дру г им функциям в про г рамме прису щ естественный параллелизм. В этом случае роль «дру г их» функций и г рает функция funcA (). PVM-задачи, порождаемые функциями main () и funcA (), выполняют различный код. Несмотря на то что задачи, порожденные функцией main (), выпол н яют идентичный код, и задачи, порожденные функцией funcA (), выполняют идентичный код, эти два набора задач совершенно различны. Этот вариант иллюстрирует возможность C++-про г раммы использовать коллекции задач для о д новременно г о решения различных проблем. Ве д ь не су щ ествует причины, по которой на про г рамму бы нала г алось о г раничение решать в любой момент времени только о д ну проблему. Вариант 4 (см. рис. 6 .4) пре д ставляет случай, ко гд а параллелизм заключен внутри объекта, поэтому порождение PVM-задач реализует один из методов это г о объекта. Этот вариант показывает, что при необхо д имости параллелизм может исходить из класса, а не из «свободной» функции.

Как и в дру г их вариантах, все PVM-задачи, порожден н ые в варианте 4, выполняют одинаковый набор инструкций, но с различными данны м и. Этот SPMD -м етод (Single Program, Multiple-Data — одна програ м ма, множество потоков данных) часто используется для реализации параллельного решения проблем некоторого типа. И то, что язык С++ обладает по д держкой объектов и средств обоб щ енного программирования на основе шаблонов, делает его основным инстру м енто м при решении подобных задач. Объекты и шаблоны позволяют С++-программисту представлять обоб щ енные игибкие решения для различных проблем с помо щ ью одной-единственной программной единицы. Наличие единой программной единицы прекрасно вписывается в модель параллелиз м а SPMD. Понятие класса расширяет модель SPMD, позволяя решать целый класс пробле м. Шаблоны дают воз м ожность решать определенный класс проблем для практически любого типа данных. Поэтому, хотя все задачи в модели SPMD выполняют один и тот же код (програ мм ную единицу), он м ожет быть предназначен для любого объекта или л юбого из его пото м ков и рассчитан на раз л ичные типы данных (азначит, и на различные объекты!). Напри м ер, в листингеб.З используется четыре PVM-задачи для генерирования четырех множеств, в каждом из которых имеется C(n,r) элементов: C(24,9), C(24,12), C(7,4) и C(7,3). В частности, влистинге 6.3 перечисляются возможные сочетания из 24 цветов, взятые по 9 и по 12. Здесь также перечисляются возможные сочетания из 7 чисел с плаваю щ ей точкой, взятые по 4 и по 3. Пояснения пообозначению C(n,r) приведены в разделе $ 6.1 («Обозначение сочетаний»).

// Листинг б.З. Создание сочетаний из заданных множеств

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

int RetCode,TaskId[4];

RetCode = pvm_spawn («pvm_generic_combination11, NULL, 0, "", 4,TaskId);

if(RetCode == 4) {

colorCombinations (TaskId[0] , 9) ; colorCombinations(TaskId[l] ,12) ; numericCombinations(TaskId[2],4); numericCombinations(TaskId[3],3); saveResult(TaskId[0]); saveResult(TaskId[l]); saveResult(TaskId[2]); saveResult(TaskId[3]); pvm_exit() ;

}

else{

cerr « «Ошибка при порождении сыновнего процесса.»

« endl; pvm_exit() ;

}

return(0);

}

В листинге 6.3 обратите внимание на порождение четырех PVM-задач: pvm_spawn(«pvm_generic_combination» ,NULL, 0, н » ,4,TaskId) ;

Каждая порожденнал задача должна выполнять програ м му с именем pvm _generic_combination. Аргу м ент NULL в вызове функции pvm_spawn() означает, что через параметр argv[] не передаются никакие опции. Значение 0 в вызове функции pvm_spawn () свидетельствует, что нас не беспокоит, на каком ко м пьютере будет выполняться наша задача. Аргу м ент TaskId представляет м ассив, предназначенный для хранения четырех целочисленных значений, который при условии успешного выполнения функции pvm_spawn () будет содержать идентификаторы каждой порожденной PVM-задачи. В листингеб.З обратите также вни м ание на вызов функций colorCombinations () и numericCombinations (). Они «дают работу» PVM-задачам. Определение функции colorCombinations () представлено в листинге 6.4.

// Листинг 6.4. Определение функции colorCombinations()

void colorCombinations(int TaskId,int Choices) {

int MessageId =1; char *Buffer; int Size; int N;

string Source(«blue purple green red yellow orange

silver gray "); Source.append(«pink black white brown light_green

aqua beige cyan "); Source.append(«olive azure magenta plum orchid violet

maroon lavender»); Source. append (" \n**) ;

Buffer = new char[(Source.size() + 100)]; strcpy(Buffer,Source.c_str()); N = pvm_initsend(PvmDataDefault); pvm_pkint(&Choices,1,1); pvm_send(TaskId,MessageId); N = pvm_initsend(PvmDataDefault); pvm_pkbyte(Buffer,strlen(Buffer),1); pvm_send(TaskId,MessageId); delete Buffer;

}

В листингеб.З от м етьте два обращения к функции colorCombinations(). Каждое из них велит PVM-задаче перечислить различное количество сочетаний цветов: C(24,9) и C(24,12). Первал PVM-задача д олжна сгенерировать 1 307 504 цветовых сочетаний, а вторал — 2 704 156. Эту работу выполняет програм м а, заданнал в вызове функции pvm_spawn (). Каждый цвет представляется строкой. Следовательно, програ мм а pvm_generic_combination (с по м ощью функции colorCombinations()) генерирует сочетания цветов, используя в качестве входных данных набор строк. Но когда она орулует «рука м и» функции numericCombinations (), показанной в листинге 6.5, в качестве входных данных используется набор чисел с плавающей точкой. Код листинга 6.3 также содержит два вызова функции numericCombinations (). Первый генерирует C(7,4) сочетаний, а второй — C(7,3).

// Листинг 6.5. Использование PVM-задач для генерирования //   сочетаний чисел

void numericCombinations(int TaskId,int Choices) {

int MessageId = 2; int N;

double ImportantNumbers[7] =

{3.00e+8,6.67e-ll,1.99e+30,

6.2. Библио т ека PVM для языка С++ 229

1.67e-27,6.023e+23,6.63e-34,

3.14159265359}; N = pvm_initsend(PvmDataDefault); pvm_pkint(&Choices,1,1) ; pvm_send(TaskId,MessageId) ; N = pvm_initsend(PvmDataDefault); pvm_pkdouble (ImportantNumbers, 5,1) ; pvm_send(TaskId,MessageId) ;

}

В функции numericCombinations () из листинга 6.4 PVM-задача использует м ассив чисел с плаваю щ ей точкой, а не м ассив байтов, представл я ю щ их строки. Поэто м у функция colorCombinations() отправл я ет свои данные PVM-задача м с по м о щ ью вызовов таких функций:

pvrt_pkbyte(Buffer,strlen(Buffer) ,1) ; pvm_send(TaskId,MessageId) ;

А функция numericCombination( ) отправляет свои данные PVM-задача м таки м образом:

pvm_pkdouble (ImportantNumbers, 5,1) ; pvn_send(TaskId,MessageId) ;

Функция colorCombinations() в листинге6.4 создает строку названий цветов, азатем копирует ее в м ассив Buffer типа char. Этот м ассив затем упаковывается и отправляется PVM-задаче с помо щ ью функций pvm_pkbyte () и pvm_send (). Функция numericCombinations() в листинге6.5 создает массив типа double и отсылает его PVM-задаче с помо щ ью функций pvm_pkdouble () и pvm_send( ). Одна функция отправляет символьный массив, а другая — массив типа double. В обоих случалх PVM-задачи выполняют одну и туже программу pvm_generic_combination. Именно здесь нас выручает преиму щ ество использования С++-шаблонов. Одинаковые задачи благодаря этому могут работать не только с различными данными, но и с различными типами данных без изменения самого кода. Использование шаблонов в С++ позволяет сделать модель SPMD более гибкой и эффективной. Программе pvm_generic_combination практически безразлично, с какими типами данных ей придется работать. Использование контейнерных С++-классов позволяет генерировать любые комбинации векторов (vector<T>) объектов. Программа pvm_generic_combination «не знает», что она будет работать с двумя типами данных. В листин г е 6.6 представлен раздел кода из программы pvm_generic_combination.

// Листинг 6.6. Использование тега MessageId для //   распознания типов данных

pvm_bufinfo (N, &NumBytes, &MessageId, &Ptid) ; if(MessageId == 1){

vector<string> Source;

Buf = new char[NumBytes];

pvm_upkbyte(Buf, NumBytes,1);

strstream Buffer;

Buffer « Buf « ends,-

while(Buffer.good())

{

Buffer » Color;

if(!Buffer.eof()){

Source.push_back(Color);

}

}

generateCombinations<string>(Source, Ptid,Value); delete Buf;

}

if(MessageId == 2){

vector<double> Source; double *ImportantNumber; NumBytes = NumBytes / sizeof(double); ImportantNumber = new double[NumBytes]; pvm_upkdouble(ImportantNumber, NumBytes,1); copy(ImportantNumber,ImportantNumber +(NumBytes + 1), inserter(Source, Source.begin())); generateCombinations<double>(Source, Ptid,Value); delete ImportantNumber;

}

Здесь используется тег MessageId, позволяю щ ий распознать, с каким типом данных м ы работае м. Но в С++ воз м ожно более удачное решение. Если тег MessageId содержит число 1, значит, м ы работае м со строка м и. Следовательно, м ожно сделать сле-лую щ ее объявление: vector<string> Source;

Если тег MessageId содержит число 2, то м ы знае м, что должны работать с числа м и с плаваю щ ей точкой, и поэто м уделае м такое объявление: vector<double> Source;

Объявив, какого типа данные будет содержать вектор Source, остальную часть функции в програ мм е pvm_generic_combination можно легко обоб щ ить. В листин- r e 6.6 обратите вни м ание на то, что каждая инструкция if() вызывает функцию generateCombinations (), которая является шаблонной. Эта шаблоннал архитектура позво л яет достичь такой степени универсальности, которая распростра н яет сце н арии SPMD и MPMD на наши PVM-програ мм ы. Мы вер н е м ся к обсуждению нашей програм м ы pvm_generic_combination после расс м отрения базовых механизмов PVM-среды. Важно отметить, что контейнерные С++-классы, потоковые классы и шаблонные алгорит м ы значительно усиливают гибкость PVM-програ мм ирования, которую невозможно было бы так просто реализовать в других PVM-средах. Именно такая гибкость создает воз м ожности д л я построения высокоорганизованных и элегантных парал л е л ьных архитектур.

Реализация модели MPMD (MIMD) с помощью PVM-и С++-средств

В то время как м оде л ь SPMD испо л ьзует функцию pvm_spawn () д л я создания некоторого чис л а задач, выпо л няю щ их одну и ту же програ мм у, но на потенциально раз л ичных наборах данных и л и ресурсов, м оде л ь MPMD испо л ьзует функцию pvm_spawn () д л я создания задач, которые выпо л няют раз л ичные програм м ы на раз л ичных наборах данных. Как с помо щ ью одной С++-программы реализовать модель MPMD (на основе PVM-функций), показано в л истинге 6.7.

6.2. Библиотека PVM для языка С++ 231

// Листинг 6.7. Использование PVM для реализации //   MPMD-модели вычисления

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

int Taskl[20]; int Task2[50]; int Task3[30]; //...

pvm_spawn («pvm_generic_combination», NULL, 1,

«hostl»,20,Taskl); pvm_spawn («generate_plans», argv, 0, "", 50, Task2) ; pvm_spawn(«agent_filters»,argv++,l, «host 3»,30,&Task3) ; //.. .

}

При выполнении кода, представленного в листинге 6.7, создается 100 задач. Первые 20 задач генерируют сочетания. Слелующие 50 по мере создания сочетаний генерируют планы на их основе. Последние 30 задач отфильтровывают самые удачные планы из набора планов, сгенерированного предыдущи м и 50 задачами. Уже только это краткое описание позволяет ощутить отличие модели MPMD от модели SPMD, в которой все программы, порожденные функцией pvm_spawn (), были одинаковы. Здесь же за работу, назначаемую PVM-задача м, «отвечают» програ мм ы pvm_generic_combination, generate_plans и agent_filters. Все эти задачи выполняются параллельно и работают с собственны м и набора м и данных, нес м отря на то что одни наборы являются результато м преобразования дру г их. Про г ра мм а pvm_generic_combination преобразует свой входной набор данных в набор, который зате м может использовать программа generate_plans. Программа generate_plans, в свою очередь, преобразует входной набор данных в набор, который может затем использовать программа agent_filters. Очевидно, что эти задачи должны обмениваться сообщениями. Эти сообщения представляют собой входную иуправляющую информацию, которая передается между процесса м и. Необходи м о также отметить, что в листинге 6.7 функция pvm_spawn () используется для размещения 20 задач pvm_generic_combination на компьютере с именем hostl. Задача generate_plans была размещена на 50 безымянных процессорах, но каждая из этих 50 задач получила при это м один и тот же аргу м ент ко м андной строки с по м ощью параметра argv. Задачи agent_filters также были направлены на конкретный ко м пьютер (с именем host 3), и каждая задача получила один и тот же аргумент командной строки посредством параметра argv. Этот пример — лишь еще одно подтверждение гибкости и мо щ и библиотеки PVM. Некоторые варианты реализации модели MPMD с использованием среды PVM показаны на рис. 6.5.

При желании мы можем воспользоваться преиму щ ествами конкрет н ых ресурсов конкретных компьютеров или же «положиться на судьбу» в виде «заказа» произвольных безымянных компьютеров. Мы можем также назначить рааличные виды работ различным задачам одновременно. На рис. 6.5 компьютер А представляет собой компьютер с массовым параллелизмом (МП-компьютер), а компьютер В осна щ ен некоторым количеством специализированных математических процессоров. Также отметьте, что PVM-среда в данном случае состоит из таких компьютеров, как PowerPCs, Spares, Crays и т.д. В одних случалх можно не беспокоиться о конкретных возможностях компьютеров в PVM-среде, а в дру г их требуется иной подход. Использование функции pvm_spawn () позволяет С++-программисту не указывать конкретный компьютер для решения задачи, когда это не важно. Но если вам известно, что компьютер осна щ ен специализированными средствами, то их можно эффективно использовать, определив соответствую щ ий параметр при вызове функции pvm_spawn ().

Рис. 6.5. Неко т орые вариан т ы модели MPMD дос т упны для реализации благодаря использованию среды PVM

§ 6.1. Обозначение сочетаний

Предположим, м ы хотели бы набрать команду програм м истов (в количестве восьми человек) из 24 кандидатов. Сколько различных ко м анд из восьми программистов можно было бы составить из этого числа кандидатов? Один из результатов, который следует из основного закона комбинаторики, говорит о том, что су щ ествуе т 735 471 различных команд, состоя щ их из восьми программистов, которые мот быть выбраны из 24 кандидатов. Обозначение C(n,r) читается как сочетание из n элементов по г(и означает количество ко м бинаций из n эле м ентов по r). Сочетание C(n,r) вычисляется по формуле:

6.3. Базовые меха н измы PVM 233

n\

r\(n-r)\

Если у нас есть м н ожество, которое представляет сочетания, например {a,b,C}, то считается, что оно совпадает с множеством {b,a,c} или {c,b,a}. Другими словами, нас интересует не порядок членов в этом множестве, а сами члены. Многие параллельные програМхМЫ, а именно программы, использую щ ие алгоритмы поиска, эвристические методы и средства искусственного интеллекта, обрабатывают огромные множества сочетаний и их близких родственников перестановок.

Базовые механизмы PVM

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

Библиотека pvmd состоит из функций, которые позволяют одной PVM-задаче взаимодействовать с другими. Эта библиотека также включает функции, которые позволяют PVM-задаче связываться со своим демоном pvmd. Базовал архитектура PVM-среды показана на рис. 6.6.

РУМтреда состоит из нескольких PVM-задач. Каждал задача должна содержать один или несколько буферов отправки сооб щ ений, но в каждый момент времени активным может быть только один буфер (он называется активным буфером отправки сообщений). Каждая задача имеет активный буфер приема сооб щ ений. Обратите внимание (см. рис. 6.6) на то, что взаимодействие между PVM-задачами реально выполняется с использованием ТСР-сокетов. Функции pvm_send () делают доступ к сокетам прозрачным. Протраммист не получает доступа к функциям ТСРчюкетов напрямую. На рис. 6.6 также показано взаимодействие PVM-задач со своими демонами pvmd с помо щ ью TCP-сокетов и взаимодействие между самими демонами с помо щ ью UDP-сокетов. И снова-таки, обра щ ения к сокетам выполняются посредством PVM-функций. Програ мм ист не должен заниматься программированием сокетов на низком уровне. PVM-функции, которые используются в этой книге, делятся на четыре следующие категории:

• управление процессами;

• упаковка сооб щ ений и их отправка;

• распаковка сооб щ ений и их получение;

• управление буфером сооб щ ений.

Несмотря на су щ ествование дру г их кате г орий РУМч^ункций (например, инфор м ационные и сервисные функции или функции групповой обработки), реко м енлуе м обратить внимание на функции обработки сооб щ ений и функции управления процессами. Дру г ие же функции булут расс м отрены в контексте програ мм, в которых они используются.

Рис. 6.6. Базовая архи т ек т ура PVM-среды

Функции управления процессами

Библиотека PVM содержит шесть часто используе м ых функций.

Функция pvm_spawn () используется для создания новых PVM-задач. При вызове этой функции м ожно указать количество создавае м ых задач, м есто их создания и аргу м енты, передавае м ые каждой задаче, напри м ер:

pvm_spawn(«agent_filters'\argv++,l,«host 3»,30,&Task3);

6.3. Базовые меха н измы PVM 235

Сикопсис

# inc lude " pvm3 . h»

int pvm_spawn(char *task, char **argv, int flag,

char *location,int ntask,int *taskids); int pvmJcill(int taskid); int pvm_exit(void) ;

intpvn_addhosts(char **hosts,int nhosts,int *status); int pvm_delhosts(char **hosts,int nhosts,int *status); int pvm_halt(void) ;

Параметр task содержит имя программы, которую должна выполнить функция pvm_spawn (). Поскольку про г рамма, которая запускается посредством функции pvm_spawn (), является автоно м ной, ей мо г ут потребоваться аргументы командной строки. Поэтомудля их передачи используется пара м етр argv. Параметр location позволяет указать, на каком компьютере должна быть выполнена задача. Пара м етр taskids содержит либо идентификаторы порождае м ых задач, либо коды состояния, представляю щ ие любые ситуации сбоя, которые м огут возникнуть во вре м я порождения процесса. Параметр ntasks определяет, сколько экзе м п л яров задачи требуется создать. Функция pvm_kill() испо л ьзуется д л я анну л ирования задачи, указанной спо м о щ ью параметра taskid. С помо щ ью этой функции можно ан н у л ировать л юбую задачу, определенную пользователем в среде PVM, за иск л ючением вызываю щ ей. Эта функция отправляет си г нал SIGTERM PVM-задаче, по д лежа щ ей уничтожению. Функция pvm_exit () используетс я д л я выхо д а вызываю щ ей задачи из сре д ы PVM. Несмотр я на возможность выво д а за д ачи из сре д ы PVM, процесс, которому прина д лежит эта за д ача, может про д олжать выполнение. Слелует иметь в виду, что задача, выполн я ю щ ал вызовы РУМ^>ункций, может выполн я ть и д ру г ую работу, которая не св я зана со средой PVM. Функцию pvm_exit () должна вызывать Любая задача, которая больше не имеет отношения к специфике PVM-обработки. Функция pvm_addhosts () позволяет динамически вносить допол н ительные компьютеры в среду PVM. Обычно при вызове функции pvm_addhosts () передается список имен добавляемых компьютеров, например: int Status [3] ;

char *Hosts[ ] = {«porthos», «dartagnan»,«athos»}; pvm_addhosts («porthose», l,&Status) ;

//.. .

pvm_addhosts (Hosts, 3 , Status) ;

Параметр Hosts обычно содержит имена компьютеров (одно или несколько), перечисленных в файле .rhosts или .xpvm_hosts. Пара м етр nhost содержит количество компьютеров, подлежа щ их добавлению в среду PVM, а пара м етр status — значение, равное значению пара м етра nhosts при успешно м выполнении функции pvm_addhosts (). Ec*m при ее вызове не удалось добавить ни одно г о ко м пьютера, значение, возвра щ ае м ое функцией, будет м еньше числа 1. Если выполнение этой функции было лишь частично успешным, значение, возвра щ аемое функцией, будет равно количеству реально добавленных компьютеров. Функция pvm_delhosts () позволяет дина м ически извлечь из среды PVM один или несколько заданных ко м пьютеров. Пара м етр hosts содержит их список, а параметр nhosts — количество выводимых компьютеров, например: pvm _delhosts («dartagnan», 1) ;

При выполнении этой функции компьютер с именем dartagnan будет извлечен из среды PVM. Функции pvm_addhosts () и pvm_delhosts () можно вызывать во время выполнения приложения. Это позволяет программисту динамически изменять размеры среды PVM. Любая PVM-задача, выполняемал на компьютере, который удаляется из PVM-среды, будет аннулирована. Демоны, выполняю щ иеся на удаляемых компьютерах (pvmd), будут остановлены. В случае возникновения аварийной ситуации на каком-либо компьютере PVM-среда автоматически удалит е г о. Значения, возвра щ аемые функцией pvm_delhosts, совпадают со значениями, возвра щ аемыми функцией pvm_addhosts (). Функция pvm_halt () прекра щ ает работу всей системы PVM. При этом все задачи и демоны (pvmd) останавливаются.

Упаковка и отправка сообщений

Гейст Бигулин (Geist Beguelin) и его колле г и так описывают модель сооб щ ений PVM-среды:

PVM-демоны и задачи могут формировать и отправлять произвольной длины сообщения, содержащие типизированные данные. Если содержащиеся в сообщениях данные имеют несовместимые форматы, то при передаче между компьютерами их можно преобразовать, используя стандарт XDR1. Сообщения помечаются во время отправки с помощью определенного пользователем целочисленного кода и мотуг быть отобраны для приема посредством адреса источника, или тега. Отправитель сообщения не ожидает от получателя подтверждения приема (квитирования), а продолжает работу сразу после отправки сообщения в сеть. Затем буфер сообщений может быть очищен или вновь использован по назначению. Сообщения буфери-зируются до тех пор, пока не будут приняты получателем. PVM-система надежно доставляет сообщения адресатам, если таковые существуют. При оправке сообщений от каждого отправителя каждому получателю их порядок сохраняется. Это означает, что если отправителем было послано несколько сообщений, они будут получены адресатом в том же порядке, в котором были отправлены.

Библиотека PVM содержит семейство функций, используемых для упаковки данных различных типов в буфер оправки. В это семейство входят функции упаковки, предназначе нн ые для символьных массивов, значений типа double, float, int, long, byte и т.д. Список рллт_рк-функций представлен в табл. 6.3.

Таблица 6.3. Фу н кции упаковки

Байты:

int pvm_pkbyte(char *cp, int count, int std) ;

Комплексные числа (комплексные числа типа double):

int pvm_pkcplx(float *xp, int count, int std) ; int pvm_pkdcplx(double *zp, int count, int std) ;

Значения типа double:

int pvm_pkdouble(double *dp, int count, int std) ;

' XDR (eXternal Data Representation) - стандарт для аппаратно-независимых структур данных, pM' работанный фирмой Sun Microsystems.

6.3. Базовые механизмы PVM 237

Окончание табл. 6.3

Значения типа f 1 о а t :

int pvm_pkfloat(float *fp, int count, int std); Значения типа int:

int pvm_pkint(int *np, int count, int std) ; Значения типа long.

int pvm_pklong(long *np, int count, int std) ; Значения типа short:

int pvm_pkshort(short *np, int count, int std) ; Строки:

int pvm_pkstr(char *cp) ;

Все функции упаковки, перечисленные в табл. 6.3, используются для сохранения массиваданных в буфере отправки. Обратите вни м ание на то, что каждая PVM-задача (см. рис.6.6) должна и м еть по крайней м ере один буфер отправки и один буфер приема. Каждал функция упаковки прини м ает указатель на м ассив соответствую щ его типаданных. Все функции упаковки, за исключением функции pvm_pkstr (), принимают общее количество элементов, подлежащих сохранению в массиве (а не количество байтов!). Для функции pvm_pkstr() предполагается, что символьный массив, с которым она работает, завершается значение м NULL. Каждал функция упаковки, за исключением функции pvm_pkstr(), в качестве последнего пара м етра прини м ает значение, которое представляет способ обхода элементов исходного массива при их упаковке в буфер отправки. Этот параметр часто называют шагом по индексу (stride). Например, если этот шаг равен четырем, то в буфер упаковки будет помещен каждый четвертый элемент исходного массива. Важно отметить, что до отправки каждого сообщения необходимо использовать функцию pvm_initsend (), которая очищает буфер и готовит его к пересылке следующего сообщения. Функция pvm_initsend() готовит буфер к пересылке сообщения в одном из трех форматов: XDR, Raw или In Place.

Формат XDR (External Z>ata .Representation) — это стандарт, используемый для описания и шифрования данных. Слелует иметь в виду, что компьютеры, включенные всрелу PVM, могут быть совершенно разными, т.е. среда PVM, например, может состоять из Sun-, Macintosh-, Crays- и AMD-компьютеров. Эти компьютеры могут отличаться размерами машинных слов и по-разному сохранять различные типы данных. В некоторых случалх компьютеры могут различаться и битовой организацией. Стандарт XDR позволяет компьютерам обмениваться данными вне зависимости от типа их архитектуры. Формат Raw используется для отправки данных в собственно м фор м ате компьютера-отправителя. При это м никакое специальное кодирование не при м еняется. Формат In Place в действительности не требует упаковки данных в буфере отправки, и адресату отправляются лишь указатели на данные и раз м ер данных. В это м случае задача-получатель напря м ую копирует данные. В библиотеке PVM эти три типа кодирования данных представляются соответствующи м и тре м я константа м и:

PvmDataDefault XDR

PvmDataRaw  Без специального кодирования

PvmDataInPlace В буфер отправки копируются лишь указатели и раз м ер данных

Вот пример: int BufferId;

BufferId = pvm_initsend(PvmDataRaw); //.. .

Здесь константа PvmDataRaw, переданнал функции pvm_initsend() в качестве параметра, означает, что данные упаковываются в буфер как есть, т.е. без специально г о кодирования. При успешном выполнении функция возвра щ ает номер буфера отправки (в данном случае он будет записан в переменную BufferId). Важно помнить, что хотя в каждый момент времени активным может быть только один буфер отправки, Любая PVM-задача может иметь несколько таких буферов, и с каждым из них связывается некоторый идентификационный номер.

В библиотеке PVM прелусмотрено несколько функций, имею щ их отношение к процелуре отправки.

Синопсис

# include « pvm3 .h»

int pvm_send(int taskid, int messageid); int pvm_psend(int taskid, int messageid,

char *buffer,int len, int datatype); int pvm_mcast(int *taskid,int ntask,int messageid);

В каждой из этих функций параметр taskid представл я ет собой идентификатор PVM-задачи, которая принимает сооб щ ение. При вызове функции pvm_mcast () параметр taskid означает коллекцию задач, представл я емых идентификаторами, которые передаютс я в массиве *taskid. Параметр messageid указывает идентификатор посылаемо г о сооб щ ени я. Идентификаторы сооб щ ений представл я ют собой целочисленные значени я, определенные пользователем. Они используются отправителем и получателем дл я идентификации сооб щ ени я, например:

pvm_bufinfo (N, &NumBytes, &MessageId, &Ptid) ; //. . .

switch(MessageId) {

case 1 : // Некоторые действия, break;

case 2 : // Другие действия, break

//. . .

}

В данном случае функци я pvm_bufinfo() используетс я дл я получени я информации о последнем сооб щ ении, прин я том в буфер приема N. Мы можем получить количество байтов, идентификатор сооб щ ени я (messageid) и узнать, кто его отправил. Знал значение messageid, мы можем выполнить соответствую щ ие логические действи я. Функци я pvm_send () посылает заданной задаче команду псевдоблокировани я, после приема которой задача блокируетс я до тех пор, пока отправитель не убедится в том, что сообщение было послано правиль н о. Задача-отправитель не ожидает реального получени я сооб щ ения. Функция pvm_psend () отправляет сооб щ ение непосредственно указанной задаче. Обратите внимание на то, что функция pvmj?send () имеет параметр buffer, используемый в качестве буфера для хранения посылаемого сообщения. Функция pvm_mcast () используется для отправки сообщения нескольким задачам одновременно. Аргументы, передавае м ые функции pvm _mcast (), включают массив идентификаторов задач-получателей сообщения (taskid), количество задач — участников «широковещания» (ntask) и идентификатор сообщения (messageid) для идентификации отправляемого сооб щ ения. На рис. 6.6 показано, что у каждой PVM-задачи есть собственный буфер отправки, который существует в течение про м ежутка вре м ени, длительности которого было бы достаточно, чтобы сообщение гарантированно дошло до адресата.

За исключение м управляющих сообщений, значение сообщений, которы м и обмениваются любые две PVM-задачи, заранее определено логикой конкретного приложения, т.е. назначение каждого сообщения должно быть заранее известно для задачи-отправителя и задачи-получателя. Эти сообщения передаются асинхронно, могут иметь любой тип данных и произвольную длину. Тем са м ы м д ля приложения обеспечивается максимальнал гибкость. Аналога м и отправляе м ых РУМкюоб щ ений являются принимаемые PVM-сооб щ ения. Так, за прие м сооб щ ений «отвечают» пять основных функций.

Синопсис

# inc lude " pvm3 . h»

int pvm_recv(int taskid, int messageid) ;

int pvm_nrecv(int taskid, int messageid) ;

int pvm_precv(int taskid, int messageid, char *buffer,

int size, int type, int sender,

int messagetag, int messagelength); int pvm_trecv(int taskid,int messageid,

struct timeval *timeout); int pvm_probe(int taskid , int messageid);

Функция pvm_recv () используется о д ни м и PVM-за д ача м и для получения сооб щ ений от других. Эта функция создает новый активный буфер, предназначенный для хранения полученного сооб щ ения. Пара м етр taskid определяет идентификатор задачи-отправителя. Пара м етр messageid идентифицирует сооб щ ение, которое послано отправителе м. Следует и м еть в виду, что задача м ожет отправить несколько сообщений, и м ею щ их различные или одинаковые идентификаторы (messageid). Если taskid = -1, то функция pvm_recv () при м ет сооб щ е н ие от любой задачи. Ec-лиmessageid = -1, то функция при м ет любое сооб щ ение. При успешном выполнении функция pvm_recv () возвра щ ает идентификатор нового активного буфера, в противном случае — отрицательное значение. После вызова функции pvm_recv () задача будет заблокирована и станет ожидать до тех пор, пока сооб щ ение не будет получено. После получения сооб щ ение считывается из активного буфера с помо щ ью одной из функций распаковки, напри м ер:

//...

float Value[10] ; pvm _recv (400002,2) ; pvn_unpkfloat(400002, Value,l) ; cout « Value..

Здесь фу н кция pvm_recv() обеспечивае т ожидание сооб щ ения от задачи, идентификатор которой равен 400002. Идентификатор сооб щ ения (messageid), полученно г о от задачи c номером 400002, должен быть равен значению 2. Затем используется функция распаковки для считывания массива чисел с плаваю щ ей точкой типа float. То г да как функция pvm_recv () вынуждает задачу ожидать до тех пор, пока она не получит сооб щ ение, функция pvm_nrecv () обеспечивает прием сообщений без блокирования. Если соответствующее сообщение не посгупает адресагу, функция pvm_nrecv () немедленно завершается. По прибытии сооб щ ения по месту назначени я функци я pvm_nrecv () сразу же завершаетс я, а активный буфер будет содержать полученное сооб щ ение. Если произойдет сбой, функция pvm_nrecv() возвратит отрицательное значение. Если сооб щ ение не поступит адресату, функция возвратит число 0. Если сооб щ ение бла г ополучно прибудет по месту назначения, функция возвратит номер ново г о активно г о буфера. Параметр taskid содержит идентификатор задачи-отправителя. Параметр messageid содержит идентификатор сооб щ ения, определенный пользователем. Если taskid = -1, функция pvm_nrecv() примет сооб щ ение от любой задачи. Если messageid = -1, эта функция примет любое сооб щ ение. При прие м е сооб щ ений с помощью функций pvm_recv () или pvm_nrecv () создается новый активный буфер, а теку щ ий буфер приема очищается.

Тогда как функции pvm_recv (), pvm_nrecv () и pvm_trecv () принимают сооб щ ения в новый активный буфер, функция pvm_precv () принимает сооб щ ение непосредственно в буфер, определенный пользователем. Параметр taskid содержит идентификатор задачи-отправителя. Параметр messageid идентифицирует получаемые сооб щ ения. Параметр buffer должен содержать реально принятое сооб щ ение. Поэтому вместо получения сооб щ ения из активного буфера с по м о щ ью одной из функций распаковки, сооб щ ение считывается напрямую из пара м етра buffer. Параметр size содержитдлину сооб щ ения в байтах. Параметр type определяет тип данных, содержа щ ихся в сооб щ ении. Параметр type может иметь следую щ ие значения:

PVM_STR   PVM_BYTE

PVM_SHORT   PVM_INT

PVM_FLOAT   PVM_DOUBLE

PVM_LONG   PVM_USHORT

PVM_CPLX   PVM_DCPLX

PVM_UINT   PVM_ULONG

Функция pvm_trecv() позволяет программисту организовать процедуру получения сооб щ ений с ограничением по времени. Эта функция заставляет вызываю щ ую задачу перейти в заблокированное состояние и ожидать прихода сооб щ ения, но лишь в течение промежутка времени, заданного параметром timeout. Этот параметр представляет собой струкгуру типа timeval, определенную в заголовке time.h, например:

#include «pvm3.h» //. . .

struct timeval TimeOut; TimeOut.tv_sec = 1000; int TaskId; int MessageId;

TaskId = pvm_parent(); MessageId = 2;

pvro_trecv(TaskId,MessageId, &TimeOut) ; //...

Здесь переменная TimeOut содержит член tv_sec, установленный равным ЮОО с. Структуру timeval можно использовать для установки временных значений в секундах и микросекундах. Структура timeval имеет следую щ ий вид:

struct timeval{

long tv_sec; // секунды

long tv_usec; // микросекунды

};

Этот пример означает, что функция pvm_trecv () заблокирует вызываю щ ую задачу максимум на 1000c. Если сооб щ ение будет получено до истечения заданных ЮОО с, функция сразу завершится. Функцию pvm_trecv () можно использовать для предотвращения бесконечных задержек и взаимоблокировок. При успешном выполнении функция pvm_trecv( ) возвра щ ает номер нового активного буфера, в противном случае (при возникновении ошибки) — отрицательное значение. Если taskid = -1, функция примет сооб щ ение от любого отправителя. Если messageid = -1, функция примет любое сооб щ ение.

Функция pvm_probe () определяет, поступило ли сооб щ ение, заданное параметром messageid, от отправителя, заданного параметром taskid. Если функция pvm_probe () «видит» указанное сооб щ ение, она возвра щ ает номер нового активного буфера. Если заданное сооб щ ение не прибыло, функция возвра щ ает число О. При возникновении сбоя функция возвра щ ает отрицательное значение.

Синопсис

#include «pvm3 .h»

int pvm_getsbuf (void) ;

int pvm_getrbuf (void) ;

int pvm_setsbuf(int bufferid);

int pvm_setrbuf(int bufferid);

int pvm_mkbuf(int Code);

int pvm_freebuf(int bufferid);

В библиотеке PVM предусмотрено шесть полезных функций управления буферами, которые можно использовать для установки, идентификации и динамического создания буферов отправки и приема. Функция pvm_getsbuf () используется для получения номера активного буфера отправки. Если теку щ его буфера отправки не существует, функция возвра щ ает число 0. Функция pvm_getrbuf () используется для получения идентификационного номера активного буфера приема. Следует иметь в виду, что при каждом получении сооб щ ения создается новый активный буфер, а теку щ ий буфер очи щ ается. Если теку щ его буфера приема не су щ ествует, функция возвра щ ает число 0. Функция pvm_setsbuf () устанавливает параметр bufferid равным номеру активного буфера отправки. Обычно PVM-задача имеет только один буфер отправки. Но иногда возникает необходимость в нескольких таких буферах. Хотя в любой момент времени активным может быть только один буфер отправки, PVM-задача может создавать дополнительные буфера отправки с по м о щ ью функции pvm_mkbuf (). Функцию pvm_setsbuf () можно использовать для установки в качестве активного буфера одного из буферов отправки, которые были созданы во время работы приложения. Эта функция возвра щ ает идентификатор предыду щ его активного буфера отправки. Функция pvm_setrbuf () устанавливает активный буфер прие м а равны м значению bufferid. По м ните, что PVM-функции распаковки работают с активны м буферо м прие м а. Если су щ ествует несколько буферов, функция pvm_setrbuf () позволит при м енить теку щ ий буфер д л я использования функция м и распаковки. При успешно м выполнении функция pvm_setrbuf () возвра щ ает идентификатор предыду щ его активного буфера. Если идентификатора буфера, переданного функции pmv_setrbuf (), не су щ ествует или он оказался недействительны м, функция возвратит одно из следую щ их сооб щ ений об ошибке: PvmBadParam или PvmNoSuchbuf. Функция pvm_mkbuf () используется для создания нового буфера сооб щ ений. Пара м етр Code определяет фор м ат данных, которые будут содержаться в это м буфере: XDR, собственный фор м ат компьютера или формат, использую щ ий указатели и размеры. Поэтому пара м етр Code мо-жет содержать одно из трех значений:

PvmDataDefault  XDR

PvmDataRaw  В зависи м ости от м арки ко м пьютера (без кодирования)

PvmDataInPlace  Используются только указатели на данные и их размер

При успешном выполнении функция pvm_mkbuf () возвра щ ает идентификатор нового активного буфера, в противном случае — отрицательное значение. Для каждого обра щ ения к функции pvm_mkbuf () , если буфер отправки больше не будет нужен, необходи м о вызвать функцию pvm_freebuf () , которая освободит память, выделенную функцией pvm_mkbuf (). Функцию pvm_freebuf () с л едует испо л ьзовать то л ько в случае, когда сооб щ ение уже отправлено и в буфере нет никакой необходимости.

Доступ к стандартному входному потоку (stdin) и стандартному выходному потоку (stdout) со стороны PVM-задач

Среда PVM связывает воедино коллекцию ко м пьютеров и представляет их для програ мм ы в виде одной логической машины с нескольки м и процессора м и. При этом возникают следующие вопросы. Какой ко м пьютер в PVM-среде должен действовать как консоль? Где будут отображаться данные, выводи м ые PVM-задачей в объект cout типа ostream? Если PVM-задача попытается принять данные с клавиатуры, то с какой и м енно клавиатуры она должна их считывать? Выходной поток stdout для каждо г о сыновнего процесса перехватывается и отправляется назначенной PVM-задаче в виде PVM-сооб щ ения. Каждый сыновний процесс наслелует инфор м ацию, которая определяет, какая за д ача д олжна принять д анные, записанные в поток stdout, и как эти д анные д о л жны быть и д ентифицированы. Вхо д ной поток каж д ого сыновнего процесса связан с устройство м /dev/null. Все, что записано в устройство /dev/null, теряется. Если устройство /dev/null открыто д л я чтения, возвра щ ается эквивалент признака конца файла. Это означает, что ко д сыновних процессов не д олжен соз д аваться в расчете на считывание вхо д ных д анных из стан д артного потока stdin (cin) или назапись выходных д анных в стан д артный поток stdout (cout). При этом потоки stdin и stdout д ля ро д ительской задачи ве д ут себя вполне ожи д аемым образом. PVM-задачи для взаимодействия между собой должны использовать сооб щ ения. Это значит, что входные данные можно принимать из сооб щ ений, каналов, об щ ей (разделяемой) памяти, переменных среды, ар г ументов командной строки или файлов. И точно так же выходные данные можно записывать в сооб щ ения, каналы, общую память и файлы.

Получение доступа к стандартному выходному потоку (cout) из сыновней задачи

Поведение выходных данных, записанных в выходной поток stdout или по м ещенных в объект cout, отличается для различных порожденных PVM-задач. Именно родительский процесс решает, что в конце концов с ними должно произойти. Ко г да выходные данные из порожденно г о потомка поме щ аются в объект cout или cerr, они перехватываются демоном pvmd и упаковываются в стандартные PVM-сообщения, которые отправляются задаче с идентификатором TaskId, заданным родителем. Родительский процесс может связать пару (TaskId, Code) с объектами cout и cerr свое г о сыновне г о процесса. Это реализуется с помо щ ью функции pvm_setopt (), которая вызывается перед порождением потомка. Если значение TaskId равно 0, сооб щ ения попадут велу щ ему демону pvmd и будут записаны в е г о журнал ре г истрации ошибок. Порожденный процесс может установить значение переменной TaskId равным 0 или значению, унаследованному от е г о родителя, или собственному значению идентификатора TaskId. Это означает, что именно родительский процесс управляет тем, куда будет записано содержимое объектов cout или cerr. Порожденнал PVM-задача может назначить дру г ие PVM-задачи для получения данных, поме щ енных в объекты cout или cerr. Обычно записью любых важных данных в потоки stdout или stdin управляет порождаю щ ая задача, а всем остальным ведает веду щ ий демон pvmd.

Резюме

Библиотека PVM, отличаю щ аяся большой г ибкостью средств, по д держивает большинство моделей параллельно г о про г раммирования. К достоинствам PVM-среды относится ее способность работать с г етеро г енны м и коллекция м и ко м пьютеров, которые м огут состоять из процессоров, отличаю щ ихся характеристика м и быстродействия, размера м и и архитектурой. По м и м о аппаратной совмести м ости, библиотека PVM прекрасно работает со стандартной С++-библиотекой и систе м ной библиотекой UNIX/Linux. В результате объединения с воз м ожностя м и C++-шаблонов, средств объектно-ориентированно г о про г ра мм ирования и коллекций алгоритмов мо щ ь PVM-среды значительно возрастает. Шаблоны прекрасно вписываются в SPMD-про г ра м мирование. А для расширени я воз м ожностей PVM-среды при испо л ьзовании моде л ей MIMD (MPMD) можно успешно использовать контейнеры и алгоритмы. В г л аве 13 мы подробнее познакомимся со сред СТв + * PVM-биб л иотеки и покажем, как ее можно использовать для С++-реализации МИ тегии «классной доски». Эта стратегия — один из основных способов решения 0 ^ блем параллельного программирования.  П **°*

Обработка ошибок, исключительных ситуаций и надежность программного обеспечения

Всегда можно изобрести суперсложные модели, чтобы объяснить множество исследуемых фактов, но ученыи, если он не философ, скорее примет самую простую теорию, которая согласуется со всеми имеющимися у негоданными.

— Алястер Pu(Alastair Rae), Quantum Physics Illusion or Reality

Одна из главных целей разработки и проектирования программного обеспечения— создать программу, которая бы отвечала требованиям пользователя и работала корректно и надежно. Пользователи требуют от ПО корректности и надежности, независимо от его конкретного назначения. Использование ненадежных программ в любой сфере — финансовой, промышленной, медицинской, научной или военной— может иметь разрушительные последствия. Зависимость людей и механизмов от ПО на всех уровнях нашего общества вынуждает его создателей сделать все возможное, чтобы их детище было надежным, робастным и отказоустойчивым. Эти требования налагают дополнительную ответственность на разработчиков и проектировщиков ПО, которые создают системы, содержащие параллелизм. Программы с параллелизмом или компоненты, которые выполняются в распределенных средах, содержат больше (по сравнению с ПО без параллелизма) программных уровней. Чем больше уровней, тем сложнее управлять таким ПО. Чем выше сложность системы, тем больше изъянов может остаться в ней невыявленными. А чем больше изъянов в ПО, тем выше вероятность того, что оно откажет, причем в самый неподходящий момент.

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

Во многих примерах программ этой книги мы не приводим кода обработки ошибок и исключительных ситуаций, чтобы не отвлекать внимание читателя от основной идеи или концепции. Однако важно иметь в виду, что использованные здесь примеры имеют вводный характер. В действительности объем кода, посвященного обработке ошибок и исключительных ситуаций в программах, включающих параллелизм или рассчитанных на распределенную среду, довольно значителен. Обработка ошибок и исключительных ситуаций должна быть составной частью проекта ПО на каждом этапе его разработки. Мы — сторонники моделирования на основе раскрытия параллелизма в области проблемы и ее решения. И именно на этапе моделирования следует заниматься разработкой моделей подсистем обработки ошибок и исключительных ситуаций. В главе 10 показано, как можно использовать язык UML (Unified Modeling Language — унифицированный язык моделирования) для визуализации проектирования систем, требующих параллельных или распределенных методов программирования. Разработка подсистем обработки ошибок и исключительных ситуаций лишь выиграет от применения средств UML и самого процесса визуализации, который ничем другим заменить нельзя. Следовательно, в качестве исходной цели вам необходимо представить надежность разрабатываемого ПО с помощью таких инструментов, как UML, диаграммы событий, событийные выражения, диаграммы синхронизации и пр. В этой главе рассматриваются преимущества ряда методов проектирования, которые способствуют визуализации проекта подсистемы обработки ошибок и исключительных ситуаций. Кроме того, в качестве основы для разработки надежного и отказоустойчивого ПО используются встроенные средства языка С++, содержащие иерархию классов исключений.

Надежность программного обеспечения

Надежность программного обеспечения— это веро я тность безотказно г о функционирования компьютерной про г ра м мы в течение заданно г о времени в заданной среде. Видеале эта веро я тность приближаетс я к 100%. Если разработчики хотят создать систему, которая будет отличатьс я безотказной работой, ее ПО должно разрабатыватьс я c использова н ие м м етодов отказоустойчиво г о про г ра мм ирования. Отказоустойчивая система — это систе м а, которая сохраняет работоспособность в результате устранения последствий ошибок ПО. Под ошибкой (fault) понимается программный дефект, который может привести к отказу в работе некоторой части ПО. В понятие «сбоя в системе программного обеспечения» (failure) мы вкладываем выполнение некоторого компонента ПО, который отклоняется от системных спецификаций. Мы согласны страктовкой ошибок и сбоев, которую предложили Муса (Musa), Ианино (Iannino) и Оку м ото (Okumoto) в своей кни г е Software Reliability.

Ошибка — это дефект в программе, который при некоторых условиях приводит к ее отказу. К отказу могут привести различные совокупности условий, причем эти условия могут повторяться. Следовательно, ошибка может быть источником не одного, а нескольких отказов. Ошибка (дефект) — это свойство программы, а не результат (свойство) ее выполнения или поведения. Именно этот смысл мы вкладываем в понятие термина «bug». Ошибка ПО — это следствие оплошности, или недоработки (error), программиста.

Ошибки, которые допускает программист или разработчик ПО, могут возникнуть из-за неверной интерпретации требований к ПО или некачественного, некорректного или недостаточно полного перевода этих требований в код. Если программист совершает оплошности такого рода, он вносит в программу ошибки, или дефекты. При выполнении дефектного кода может произойти сбой программы. Ошибки ПО можно обнаружить только при выполнении кода. Очистить программу от ошибок, а следовательно, и не допустить возможность отказа, позволяет процесс тестирования и отладки ПО. Обратите внимание на то, что мы используем термины «дефект» и «ошибка» взаимозаменяемо. Термин «оплошность» мы относим к допускаемым программистом промахам, которые являются причиной дефектов ПО. Отказоустойчивость—это свойство, которое позволяет некоторой части ПО оставаться в исправном состоянии или восстанавливать работоспособность после программных сбоев, вызванных ошибками, внесенными в ПО в результате недоработки программистов.

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

Отказы в программных и аппаратных компонентах

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

Рис.7.1. Схема аппаратных компонентов, а также уровней ПО, которые могут содержать ошибки

На рис. 7.1 мы отделили аппаратные компоненты от программных, поскольку методы обработки аппаратных сбоев часто отличаются от методов обработки программных ошибок. Здесь также выделены различные уровни ПО. Некоторые из них находятся вне «досягаемости» разработчика (т.е. он не может ими управлять напрямую) и требуют специального рассмотрения процесса обработки исключений и ошибок. На этапах проектирования, разработки и тестирования ПО обязательно следует принимать во внимание возможность аппаратных сбоев и наличия ошибок в различных «слоях» ПО. Для программ, которым присущ параллелизм или состоящих из распределенных компонентов, следует учитывать дополнительные обстоятельства, весьма «благоприятные» для возникновения аппаратных сбоев. Например, в распределенных программах используется взаимодействие аппаратных и программных средств. Ошибка, «закравшался» в компонент, отвечающий за это взаимодействие, может привести к отказу всей системы. Программы, разработанные для параллельной работы процессоров, могут сбоить, если ожидаемое количество процессоров окажется недос-гупным. Даже если средства связи и процессоры прекрасно отработали при загрузке системы, ее отказ возможен в любой момент после начала функционирования. Исключительная ситуация может возникнуть в любом из компонентов оборудования и на любом уровне ПО. Кроме того, каждый программный уровень может содержать дефекты, которые необходимо каким-то образом обрабатывать. На этапе проектирования ПО следует рассматривать возможные исключительные ситуации и ошибки в программах, присущие каждому уровню ПО в отдельности. Ведь варианты восстановления приложения после возникновения исключительных ситуаций и исправления ошибок, которые возможны на уровне 2, отличаются от вариантов, применимых к уровню 3. К сбоям, которые возможны на различных уровнях ПО и в аппаратных компонентах, следует добавить сбои, характеризующиеся архитектурной областью локализации, специфической для каждого приложения. Например, на рис. 7,2 показано, как по мере увеличения дистанции между задачами возрастает уровень сложности обработки ошибок и исключительных ситуаций.

Рис. 7.2. Зависимость увеличения уровня сложности обработки исключительных ситуаций и ошибок от увеличения дистанции между логическим местоположением задач

Чем больше в программных или аппаратных компонентах дистанция между параллельно выполняющимися задачами, тем более высокий уровень организации требуется для проектирования компонентов обработки исключительных ситуаций иошибок. Изучив рис. 7.1 и 7.2, можно понять: для того, чтобы спроектировать и разработать надежное ПО, необходимо прелусмотреть не только, какие возможны исключительные ситуации и ошибки, но и где они могут возникнуть.

Определение дефектов в зависимости от спецификаций ПО

Спецификация ПО — это своего рода «эталон», позволяющий определить, имеет ли данная часть ПО дефекты. Мы не можем оценить корректность программных компонентов без доступа к программным спецификациям. Спецификация ПО содержит описание и требования, из которых должно быть ясно, что должен делать данный программный компонент и чего он делать не должен. Общеизвестно, что довольно трудно написать полные, исчерпывающие и точные спецификации. Спецификации могут представлять собой формальные документы и требования, составленные конечными пользователями, аналитиками, специалистами по созданию пользовательского интерфейса, специалистами в предметной области и др. Спецификации могут также выглядеть как множество целей и не жестко определенных задач, устно излагаемых пользователями проектировщикам и разработчикам ПО. Любое отклонение компонента ПО от его спецификации является дефектом. Чем выше качество спецификации, тем проще выявить дефекты и понять, где программист сделал ошибки. Если спецификация проекта расплывчата, с плохо определенными элементами и нечетко описанными требованиями, то определение протраммных дефектов для такого проекта представляет собой движущуюся мишень. Если спецификации неоднозначны, то трудно сказать, что дефектно, а что нет. Точно так же невозможно утверждать, прав ли был разработчик. Туманно определенные спецификации являются причиной так же туманно определяемых ошибок. В таких условиях создание отказоустойчивого и надежного ПО попросту невозможно.

Обработка ошибок или обработка исключительных ситуаций?

В общем случае ошибки ПО (которые являются результатом оплошности или недоработки программиста) должны быть обнаружены и исправлены на этапах тестирования, перечисленных в табл. 7.1.

Таблица 7.1. Типы тестирования, используемые в процессе разработки ПО

Tun тестирования

Описание

Блочное тестирование, или шстирование элементов (unit testing)

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

Проверка взаимодействия и функционирования компонентов системы (integration testing)

Тестируется некоторая совокупность элементов. Элементы объединяются влогические группы, и каждая группатестирует-ся как единый блок (элемент). Эти группы могут подвергаться одинаковым проверкам. Если группа элементов проходит тест, ее присоединяют к тестируемой совокупности, которая в свою очередь должна быть протестирована с новым дополнением. Увеличение количества элементов, подлежащих тестированию, должно подчиняться формулам комбинаторики

Регрессивное теcmupoвaние (regression testing)

Программные модули должны повторно тестироваться, если в них были внесены изменения. Регрессивное тестирование дает гарантию, что изменение любого компонента не приведет к потере функциональности

Испытания в утяже-ленном режиме (stress testing)

Тестирование, которое проводится для компонента или всей системы при предельных и «запредельных» значениях входных параметров. Использование траничных условий позволяет определить, что может произойти с компонентом или системой в нештатных ситуациях

Эксплуатационные испытания (operational testing)

Тестирование системы с полной нагрузкой. Для этого используется реальнал среда, создающая реальную нагрузку. Этот тип тестирования также применяется для определения производительности системы в совершенно незнакомой среде

Тестирование спецификации (specification testing)

Компонент проверяется при сравнении с исходными спецификациями. Именно спецификация устанавливает, какие компоненты включены в систему и какие взаимоотношения должны быть между ними. Этот этап является частью процесса верификации ПО

Приемочные испытания (acceptance testing)

Тестирование этого типа выполняется конечным пользователем модуля, компонента или системы для определения его (ее) производительности. Этот этап является частью процесса аттестации ПО

Во время процесса тестирования и отладки программные дефекты должны быть обнаружены и ликвидированы. Однако исключительные ситуации (исключения) обрабатываются во время выполнения программы. Следует различать исключительные и нежелательные условия. Например, если мы спроектировали программу, которая будет добавлять в список числа, вводимые пользователем, а пользователь будет вводить и числа, и символы, которые не являются числами, то такая ситуация относится к нежелательной, а не к исключительной. Мы должны проектировать программы, которые были бы робастными, т.е. устойчивыми к ошибкам, прелусматривал проверку корректности входных данных. Ввод данных в программу должен быть организован таким образом, чтобы пользователь был вынужден вводить данные, которые требуются нашей программе для надлежащего выполнения. Если, например, спроектированный нами компонент программы сохраняет информацию на внешнем устройстве, и программа попадает в ситуацию отсутствия свободного пространства на этом устройстве, то такие условия работы программы также можно назвать нежелательными, а не исключительными, или экстраординарными. Исключительные ситуации мы связываем с необычными условиями, а не с нежелательными. Методы обработки исключительных ситуаций предназначены для непредвиденных обстоятельств. Ситуации же, которые являются нежелательными, но вполне возможными и потому предсказуемыми, должны обрабатываться с применением обычной программной логики, например:

if <входные данные неприемлемы, то>

<повторно запрашиваем входные данные>

else

<выполняем нужную операцию> end if

Такая проверка условий — одна из основополагающих граней искусства программирования. Продемонстрированный стиль программирования позволяет не допустить возникновения многих проблем, но эта модель ситуации не «дотягивает» до определения исключительной. Существуют различия между дефектами и исключительными ситуациями, а также между исключительными ситуациями и нежелательными условиями. С дефектами справляются путем тестирования и отладки. Нежелательные условия обрабатываются в рамках обычной программной логики, а исключительные ситуации — методами обработки исключений. Различия между характеристиками обработки ошибок, исключений и нежелательныхусловий сведены в табл. 7.2.

Таблица7.2. Различия между характеристиками обработки ошибок,  исключений и нежелательных условий

Обработка ошибок

Обработка исключительных ситуаций

Обработка нежелательных условий

Логические ошибки обнаруживаются на этапе тестирования и отладки

Описывает непредвиденные условия во время выполнения

Описывает нежелательные условия, которые весьма вероятны во время выполнения

Корректно работающие программы не содержат ошибок

Корректно написанные программы могут попадать в исключительные ситуации

Корректно написанные программы могут попадать в нежелательные ситуации

Для предупреждения и исправления ошибок используется программная логика

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

Для исправления нежелательных условий используется программная логика

Поддерживается нормальный ход выполнения программы

Нормальный ход выполнения программы нарушается

Делается попытка поддержать нормальный ход выполнения программы

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

Рис. 7.3. Архитектура упрощенного компонента обработки ошибок

Компонент 1 на рис. 7.3— это простой компонент отображения (map), который содержит список номеров ошибок и их описания. Компонент 2 содержит объект, который преобразует номера ошибок в адреса переходов, функций или подсистем. По номеру ошибки компонент 2 определяет направление перехода. Компонент 3 преобразует номера ошибок в иерархическую структуру отчетов и логику отчетов. Иерархическая структура отчетов содержит данные о том, кого (или что) необходимо уведомить об ошибке. Логика отчетов определяет, что должно включать это уведомление. Компонент 4 содержит два объекта отображения. Первый преобразует номера ошибок в объекты, назначение которых — скорректировать некоторые ситуации сбоя (условия). Второй преобразует номера ошибок в объекты, которые возвращают систему в стабильное или хотя бы частично стабильное состояние. Упрощенный компонент обработки ошибок, показанный на рис. 7.3, можно применить к ПО любого размера и формы. Характер использования компонентов обработки ошибок и исключительных ситуаций определяется требуемой степенью надежности ПО.

Надежность ПО: простой план

Напомним, что мы различаем ошибочные и неудобные (нежелательные) условия. Неудобные или нежелательные условия должны обрабатываться обычной программной логикой. Ошибки (дефекты) требуют специального программирования. В книге Страуструпа Язык программирования С++ (1997) автор приводит четыре основных альтернативных действия, которые может предпринять программа при обнаружении ошибки. По мнению Страуструпа, программа, выявив проблему, которую невозможно обработатьлогически, должна реализовать один из следующих вариантов поведения.

• Вариант1. Завершить программу.

• Вариант 2. Возвратить значение, обозначающее «ошибку».

• Вариант 3. Возвратить значение, обозначающее нормальное завершение, и оставить программу в состоянии с необработанной ошибкой.

• Вариант 4. Вызвать функцию, предназначенную для вызова в случае ошибки.

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

Очевидно, что завершать программу при каждом обнаружении ошибки попросту неприемлемо. Здесь мы согласны со Страуструпом. В таких случалх следует поступать более изобретательно. Что касается варианта 2, то примитивный возврат значения ошибки действительно может помочь в некоторых ситуациях, но далеко не во всех. Не каждое возвращаемое значение может интерпретироваться как успешное или неудачное. Например, если значение, возвращаемое некоторой функцией, имеет вещественный тип, и область определения функции включает как отрицательные, так и положительные значения, то какое тогда значение функции можно использовать для представления ошибки? Другими словами, это не всегда возможно. С нашей точки зрения, вариант 3 также неприемлем. Ведь если «изготовитель» возвращает значение, обозначающее нормальное завершение, «потребитель» продолжит работу, предположив, что его запрос был выполнен, а это может вызвать еще большие проблемы. Осталось рассмотреть вариант 4. Он требует более внимательного подхода при обсуждении обработки как ошибок, так и исключительных ситуаций.

План А: модель возобновления, план Б: модель завершения

При обнаружении ошибки или исключительной ситуации существует два основных плана для реализации варианта4. Первый план состоит в попытке скорректировать условия, которые вызвали сбой, а затем возобновить выполнение с точки, в которой была обнаружена ошибка или исключительнал ситуация. Этот подход называетс я возобновлением. Второй план состоит в признании (подтверждении) ошибки или исключительной ситуации и постепенном выходе из подсистемы или подпрограммы, в которой возникла проблема. Постепенный выход реализуется путем закрытия соответствующих файлов, разрушения требуемых объектов, регистрации (если это возможно) ошибки, освобождения соответствующей памяти и обработки устройств, которые этого требуют. Такой подход называется завершением, и его не следует путать с понятием резкого выхода из программы. Оба плана вполне действенны и в различных ситуациях оказываются весьма полезными. Прежде чем обсуждать способы реализации моделей возобновления и завершения, имеет смысл рассмотреть средства обработки ошибок и исключительных ситуаций, которые прелусмотрены в языке С++.

Использование объектов отображения для обработки ошибок

Компонент отображения (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, то обработчик исключений мог бы применить их для решения проблемы либо для восстановления работоспособного состояния программы. Для создания объектов исключений можно также использовать встроенные С++-классы исключений.

Классы исключений

Стандартная библиотека классов С++ содержит девять классов исключений, разделенных на две основные группы (группа динамических ошибок и группа логических ошибок), которые приведены в табл. 7.3. Группа динамических ошибок представляет ошибки, которые трудно предотвратить. В группу логических ошибок входят ошибки, которые «теоретически предотвратимы».

Таблица 7.3. Классы динамических и логических ошибок

Классы динамических ошибок

Классы логических ошибок

range_error

domain_error

underflow_error

invalid_argument

overflow_error

length_error

out_of_range

Классы runtime__error

На рис. 7.4 показана схема отношений между классами для семейства классов runtime_error. Это семейство выведено из класса exception. Из класса runtime_error выведено три класса: range_error, overflow_error Hunderflow_error, которые сооб щ ают об ошибках промежуточных вычислений (об ошибках выхода за границы диапазона, переполнения и потери значимости). Потомки класса runtime_error наслелуют основное поведение от своего предка, класса exception (имеется в виду метод what (), оператор присваивания operator= () и конструкторы класса обработки исключений).

Рис. 7.4. Схема отношений между классами для семейства классов runtime_error

Каждый класс обеспечивает определен н ый диапазон наслелуемых функций, которыми программист может воспользоваться для конкретной программы. Например, классы defect_response и exception_response, созданные в листингах 7.1 и 7.2, можно вывести как из класса runtime_error, так и из класса logic_error. Но сначала полезно рассмотреть работу базовых классов исключений без специализации. В листинге 7.3 показано, как можно сгенерировать объекты классов exception и logic__error.

// Листинг 7.3. Генерирование объекта класса exception и

// объекта класса logic_error

try{

exception X; throw(X) ;

} catch(const exception &X) {

cout « X.what() << endl;

}

try{

logic_error Logic(«JIorn4ecKaH ошибка»); throw(Logic);

} catch(const exception &X) {

cout << X.what() « endl;

}

Объекты базового класса exception обладают лишь конструкторами, деструкторами, средствами присваивания, копирования и простейшего вывода отчетной информации. При сбое они не способны его скорректировать. Здесь можно рассчитывать лишь на вывод сообщения об ошибке, возвращаемого методом what() классов исключений. Это сообщение будет определяться строкой, переданной конструктору для объекта класса logic_error. В листинге7.3 переданная конструктору строка «Логическая ошибка» будет возвращена методом what() в catch-блoкe и выведена в виде сообщения.

Классы logic_error

Семейство классов logic_error выведено из класса exception. И в самом деле, большинство функций классов этого семейства также унаследовано от класса exception. Класс exception содержит метод what() , используемый для уведомления пользователя о возникшей ошибочной ситуации. Каждый класс logic_error-семейства содержит конструктор, используемый для привязки сообщения, специфического для данного конкретного класса. Схема отношений между классами для семейства logic_error показана на рис. 7.5.

Рис. 7.5. Схема отношений между классами для семейства классов logic_error

Подобно классам семейства runtime_error эти классы также предназначены для последующей специализации. Если пользователь не расширит их функциональность, они не смогут сделать ничего, кроме как уведомить об ошибке и ее типе. Упомянутые выше девять классов исключений общего назначения не обеспечивают никаких действий по корректировке ситуации или обработке ошибок.

Выведение новых классов исключений

Классы исключений можно использовать как есть, т.е. просто для вывода сообщений с описанием происшедших ошибок. Но в качестве метода обработки исключений такой подход практически бесполезен. Просто знать о возникновении исключительной ситуации — не слишком большой шаг на пути повышения надежности ПО. Реальная польза иерархии классов исключений состоит в обеспечении ими архитектурной карты дорог для проектировщика и разработчика. Классы исключений предусматривают основные типы ошибок, которые разработчик может уточнить. Многие исключительные ситуации, которые возникают в среде выполнения, можно было бы отнести к категориям, «охватываемым» семействами классов logic_error или runtime_error. В качестве примера возьмем класс runtime_error и продемонстрируем, как можно «сузить» его специализацию. Класс runtime_error является потомком класса exception. Специализацию класса можно определить с помощью механизма наследования. Вот пример:

class file_access_exception : public runtime_error{

protected:

//...

int ErrorNumber;

string DetailedExplanation;

string FileName;

//...

public:

virtual int takeCorrectiveAction(void);

string detailedExplanation(void);

//...

};

Здесь класс file_access_exception наслелует класс runtime_error и получает специализацию путем добавления нескольких членов данных и функций-членов. В частности, добавляется метод takeCorrectiveAction (). Этот метод можно использовать в качестве вспомогательного средства, с помощью которого обработчик исключений мог бы выполнять работу по коррекции ситуации и восстановлению работоспособности программы. Объект класса file_access_exception «знает», как идентифицировать взаимоблокировку и как ее прекратить. Кроме того, он содержит специализирован н ую логику, предназначенную для борьбы с вирусами, которые могут разрушить файлы, а также специальные средства на случай неожиданного прерывания процесса передачи файлов. Мы можем использовать объекты класса file_access_exception вместе со средствами генерирования, перехвата и обработки исключений, прелусмотренными в языке С++. Рассмотрим пример.

try{

//...

fileProcessingOperation();

//.. .

} catch(file_access_exception &E) {

cerr « E.what() << endl;

cerr « E.detailedExplanation() « endl;

E.takeCorrectiveAction();

// Обработчик выполняет дополнительные действия

// по корректировке ситуации.

//.. .

}

Этот метод позволяет создать объекты отображения ExceptionTable, подобные объектам отображения ErrorTable из л истингов 7.1 и 7.2. При этом код обработчика исключений можно упростить за счет испо л ьзования вертикального и горизонтального полиморфизма.

Защита классов исключений от исключительныхситуаций

Объекты исключений генерируются в случае, когда некоторый программный компонент сталкивается с аномалией программного или аппаратного характера. Однако следует отметить, что объекты исключений сами не должны генерировать исключений. Ведь если окажется, что обработка одной исключительной ситуации слишком сложна и потенциально может вызвать возникновение другой исключительной ситуации, то схему такой обработки необходимо пересмотреть, упростив ee везде, где только это возможно. Механизм обработки исключительных ситуаций неоправданно усложняется именно тогда, когда код обработчика может генерировать исключения. Именно поэтому большинство методов в классах исключений содержат пустые спецификации throw-инструкций.

// Объявление класса исключения.

class exception {

public:

exception() throw() {}

exception(const exception&) throw() {}

exception& operator=(const exception&) throw() {return *this;}

virtual ~exception() throw() {}

virtual const char* what() const throw();

};

Обратите внимание на отсутствие аргументов в объявлениях throw() -методов. Пустые аргументы означают, что данный метод не может сгенерировать исключение [12]. Если он попытается это сделать, во время компиляции будет выдано сообщение об ошибке. Если базовый класс не может сгенерировать исключение, то соответствующий метод в любом производном классе также не сделает этого.

Диаграммы событий, логические выражения и логические схемы

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

Illustration 1: Рис. Рис. 7.6 Простая диаграмма событий

Мы используем диаграммы событий для построения схемы действия обработчика исключительных сигуаций. На рис. 7.6 схематично изображена система, состоящая из семи задач, помеченных буквами А, В, С, D, E, F и H. Обратите внимание на то, что каждая метка (обозначающал задачу) расположена над переключателем. Если переключатели закрыты, компонент функционирует, в противном случае — нет. Крайняя точка слева представляет начало, а крайняя точка справа — конец выполнения. Для успешного завершения программы необходимо найти путь через действующие компоненты. Попробуем продемонстрировать, как применить эгу диаграмму к нашему случаю обработки исключений. Предположим, что мы начинаем программу с выполнения задачи А. Чтобы успешно завершить программу, необходимо корректно решить обе задачи А и С. На языке диаграммы это означает, что переключатели А и С должны быть закрыты. На нашей диаграмме событий переключатели А и С находятся на одной ветви, что свидетельствует об их параллельном выполнении. Если произойдет отказ в любой из этих задач (А или С), будет сгенерировано исключение. Обработчик исключений мог бы снова начать выполнение задач А и С. Однако анализ нашей диаграммы событий показывает, что завершение всей программы будет успешным, если успешным будет выполнение либо ветви АС, либо ветви DE, либо ветви FBH. Поэтому мы проектируем наш обработчик исключений таким образом, чтобы он выполнял один из альтернативных наборов компонентов (например, DE или FBH). Наборы компонентов (AC, DE и FBH) связаны между собой отношением ИЛИ. Это значит, что к успешному завершению программы приведет успешное выполнение любого набора параллельно выполняемых компонентов. Таким образом, простая диаграмма событий (см. рис. 7.6) позволяет понять, как следует построить обработчик исключений. Выражение

S = (AC + DE + FBH)

часто называют логическим выражением, или булевым. Это выражение означает, что для пребывания системы в устойчивом состоянии (т.е. ее надежной работы) необходимо успешное выполнение одной из следующих групп задач: (А и С) или (D и E) или (F и В и H). По диаграмме событий нетрудно также понять, какие комбинации отказов компонентов могут привести к отказу системы. Например, если откажут только компоненты E и F, то система успешно отработает, если при этом «не подвелут» компоненты А и С. Но если бы дали сбой компоненты А, D и H, то систему в этом случае уже ничего бы не спасло от отказа. Диаграмма событий и логическое выражение — это очень полезные средства для описания параллельных зависимых и независимых компонентов, а также для построения схемы действия обработчика исключительных ситуаций. Например, используя диаграмму событий (см. рис. 7.6), мы можем наметить следующий подход к обработке исключений для нашего примера:

try{

start(task А and В)

} catch(mysterious_condition &E) {

try{

if(!(А && В)){

start(F and В and H)

}

} catch(mysterious_condition &E){

start(D and E)

}

};

Этот вид стратегии призван улучшить надежность системы. Слелует также отметить, что параллельно выполняемые программные компоненты и альтернативные варианты для планирования безотказной работы системы можно отобразить с помощью традиционной логической схемы, показанной на рис. 7.7.

Рис. 7.7. Логическая диаграмма, отображающая три И-схемы, объединяемые с помощью ИЛИ-схемы, для успешного завершения работы системы

Итак, на рис. 7.7 показано три И-схемы, объединяемые на основе ИЛИ-отношений для получения результата S (который означает успешное завершение работы системы). Диаграмма событий (см. рис. 7.6) и логическая схема (см. рис. 7.7) — это примеры простых методов, которые можно использовать для визуализации критических путей (ветвей) и критических компонентов в некоторой части ПО. После идентификации критических путей и компонентов разработчик должен прелусмотреть ответные действия, которые должна выполнить система в случае, если откажет любой из критических компонентов. Если при этом используется модель завершения, то обработчик исключений не делает попытку возобновить выполнение ПО с точки, в которой возникла исключительная ситуация. Вместо этого осуществляется выход из функции или процедуры, в которой произошло исключение, и предпринимаются действия по пе-револу системы в стабильное (насколько это возможно) состояние. Но если используется модель возобновления, то корректируются условия, создавшие аномалию, и программа возобновляется с точки, в которой возникла исключительнал ситуация. Важно отметить, что при реализации модели возобновления возможны определенные трудности. Например, предположим, что наш код содержит слелующую последовательность вложенных вызовов процедур:

try{

А вызывает В

В вызывает С

С вызывает D

D вызывает E

E сталкивается с аномалией, с которой не может справиться

}

catch(exception Q) {

}

Если в процелуре E возникла аномалия и было сгенерировано исключение, то возможна проблема со стеком вызовов. Нужно также решить вопрос с разрушением объектов и проблему «подвешенных» значений, возвращаемых процедурами. Подумайте, что произойдет, если процедуры С и D являются рекурсивными? Даже если мы откорректируем условие, вызвавшее исключение в процедуре E, то как вернуть программу в состояние, в котором она пребывала непосредственно перед выбросом исключения? А ведь мы должны сохранить информацию в стеке, таблицы создания и разрушения объектов, таблицы прерываний и пр. Это потребует больших затрат и обеспечения сложного взаимодействия между вызывающими и вызываемыми сторонами. Bce вышесказанное обозначило лишь поверхностный слой трудностей. Из-за сложности реализации модели возобновления и благодаря тому факту, что разработка больших систем может обойтись без нее, для С++ была выбрана модель завершения. В книге [44] Страуструп дает полное обоснование того, почему комитет ANSI в конце концов выбрал для механизма обработки исключений модель завершения. Но если, несмотря на то что модель возобновления действительно сопряжена с большими трудностями, надежность и бесперебойность ПО являются критичными факторами, то лля реализации этой модели все же имеет смысл приложить соответствующие усилия. При этом стоит иметь в виду, что С++-средства обработки исключений можно использовать и для реализации модели возобновления.

Резюме

Создание надежного ПО — серьезное занятие. К вопросам обработки исключительных ситуаций и исправления ошибок следует подходить с особой ответственностью. Тщательное тестирование и отладка каждого компонента ПО должны быть основными средствами защиты от программных дефектов. Обработку исключений необходимо внести в систему или подсистему ПО после того, как оно прошло этап строжайшего тестирования. Механизм генерирования исключений не следует использовать в качестве общего правила для обработки ошибок, поскольку он нарушает обычный ход выполнения программы. К средствам генерирования исключений следует прибегать только после того, как будут исчерпаны все остальные меры. Программист, который планирует проектировать более полные и полезные (с его точки зрения) классы исключений, должен использовать стандартные классы обработки исключений в качестве архитектурных «дорожных карт». Стандартные классы, не специализированные с помощью наследования, могут лишь уведомлять об ошибках. Можно создать более полезные классы исключений, которые бы обладали корректирующими функциями и большей информативностью. В общем случае, как модель завершения, так и модель возобновления позволяют продолжать выполнение программы. Обе эти модели предлагают альтернативу простому прерыванию программы при обнаружении ошибки. Более полное рассмотрение темы обработки исключительных ситуаций можно найти в работе [44].

Распределенное объектно-ориентированное программирование

Итак, основное различие между человеком и андроидом состоит в том, что человек приходит со своим собственным «я», чего нельзя сказать о роботе.

— Кэри де Бессонет(Cary G deBessonet), Towards А Sentential 'Reality' for the Android

Распределенные объекты — это объекты, которые являются частью одного приложения, но размещены в различных адресных пространствах Адресные пространства могут относиться к одному или различным компьютерам, связанным сетью или другими средствами коммуникации. Объекты, включенные в приложение, могли быть изначально нацелены на совместную работу или разрабатываться различными отделами, подразделениями, компаниями или организациями в различное время и с разными целями. В категорию распределенных объектно-ориентированных приложений мотут попадать приложения из большого диапазона: от одноразовой собранной совместными усилиями коллекции несвязанных объектов до мульти-приложения, «разновозрастные» объекты которого разбросаны по сети Internet. Местоположение объектов может быть самым разнообразным: intranet (корпоративная локальнал сеть повышенной надежности с ограниченным доступом, использующал сетевые стандарты и сетевые программно-аппаратные средства, аналогичные Internet), extranet (экстрасеть— объединение корпоративных сетей различных компаний, взаимодействующих друг с другом через Internet) и Internet. Согласно большинству описаний распределенных объектов, они (объекты) могут быть реализованы в различных языках, например С++, Java, Eiffel и Smalltalk. Распределенные объекты могут играть множество ролей. Б одних сигуациях такой объект (или коллекция объектов) используется в качестве сервера, который способен обеспечить услуги, например, по доступу к базе данных, по обработке данных или их передаче. В других ситуациях объекты играют роль клиентов. Распределенные объекты можно использовать в таких объединенных моделях решения проблем, как «классная доска» и мультиагентные системы. Помимо объединенных моделей, распределенные объекты могут быть полезны для реализации таких парадигм параллельного программирования, как SPMD и MPMD. Объектам одного приложения не требуется специального протокола для связи между собой. Коммуникация достигается за счет обычного вызова методов, передачи параметров и использования глобальных переменных. Но, поскольку распределенные объекты расположены в различных адресных пространствах, здесь не обойтись без методов межпроцессного взаимодействия и во многих случалх необходимо сетевое программирование.

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

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

• Для выполнения некоторой важной работы или решения насущной проблемы необходимо скооперировать объекты, различающиеся временем разработки, разработчиками и местоположением.

• Агенты, реализованные как объекты, отличающиеся узкой специализацией, требуют собственных адресных пространств, поскольку они запускаются как отдельные процессы.

• Объекты используются в качестве базовых модулей, которые реализованы как отдельные программы, каждая из которых имеет собственное адресное пространство.

• Объекты реализованы в SPMD- или МРМП-архитектуре, рассчитанной на использование параллельного программирования, причем эти объекты расположены в различных процессах и на различных компьютерах.

В объектно-ориентированном приложении выполняемая программой работа делится между несколькими объектами. Эти объекты представляют собой модели определенной реальной личности, реального места, предмета или идеи. Выполнение объектно-ориентированной программы вынуждает ее объекты взаимодействовать между собой в соответствии с правилами, заложенными в этой модели. В распределенном объектно-ориентированном приложении некоторые взаимодействующие объекты будут создаваться различными программами, которые, возможно, выполняются на различных компьютерах. В главе 3 упоминалось о том, что каждая выполняемал программа включает один или несколько процессов. Каждый процесс обладает собственными ресурсами. Например, любой процесс имеет собственную память, дескрипторы файлов, стековое пространство, идентификатор и т.п. Задачи, выполняемые в одном процессе, не имеют прямого доступа к ресурсам, принадлежащим другому процессу. Если задачам, выполняемым в одном процессе, необходима информация, хранимая в памяти другого процесса, то эти два процесса должны явно обменяться информацией с помощью файлов, каналов, общей памяти, переменных среды или сокетов. Объекты, которые принадлежат различным процессам и нуждаются во взаимодействии между собой, также должны использовать один из перечисленных выше способов явного обмена информацией. Как правило, С++-разработчик при разработке распределенного объектно-ориентированного приложения сталкивается с необходимостью решения следующих проблем.

• Деко м позиция задачи и ее решения на м ножество объектов, приче м некоторые из них будут принадлежать рааличным процесса м и раз м ещаться на разных компьютерах.

• Обеспечение связи между объектами, принадлежащими различным процесса м (адресным пространствам).

• Синхронизация взаимодействия между локальны м и и удаленны м и объектами.

• Обработка ошибок и исключений в распределенной среде.

Декомпозиция задачи и инкапсуляция ее решения

Проектирование объектно-ориентированного программного обеспечения — это процесс перевода требований к ПО в проект, в котором с помощью объектов моделируется каждый аспект разрабатываемой системы и выполняемой ею работы. Центральное место в этом проекте отводится структуре и иерархии коллекций объектов, а также их взаимоотношениям и взаимодействиям. Для поддержки понятия модели ПО в С++ используется ключевое слово class. Существует два базовых типа моделей. Первый тип модели — масштабированное представление некоторого процесса, концепции или идеи. Этот тип модели используется для анализа или экспериментирования. Например, класс применяется для разработки модели молекулы, т.е. с помощью концепции С++-класса можно смоделировать гипотетическую структуру некоторого химического процесса, происходящего в молекулах. Программным путем можно затем изучить поведение молекулы при внедрении новых групп атомов. Второй тип модели ПО — воспроизведение некоторой реальной задачи, процесса или идеи. Цель этой модели — заставить некоторую часть системы ПО или приложения функционировать подобно ее «прототипу». В этом случае ПО занимает место некоторого компонента или некоторого физического предмета в неавтоматизированной системе. Например, мы можем использовать концепцию класса для моделирования калькулятора. При корректном моделировании всех его характеристик и поведения можно создать экземпляр этого класса и использовать в качестве настоящего калькулятора. Программный калькулятор здесь будет играть роль реального калькулятора. Таким образом, смоделированный нами класс может служить в качестве виртуального лублера некоторого реального лица, места, предмета или идеи. Главное в программной модели — ухватить суть реального предмета.

Декомпозиция (decomposition) — это процесс разделения задачи и ее решения на ряд подзадач, коллекций объектов и принципов взаимоотношений между этими объектами. Аналогично инкапсуляция (encapsulation) — это моделирование характеристик, атрибутов и поведения некоторого лица, места, предмета или идеи с помощью С++-конструкции class. Такое моделирование (инкапсуляция) и декомпозиция являются частью этапа проектирования объектно-ориентированного ПО. Объектно-ориентированные приложения, которые содержат распределенные объекты, вносят в процесс проектирования дополнительный уровень сложности. С точки зрения «чистого» проектирования местоположение объектов в приложении не должно влиять на разработку атрибутов и характеристик этих объектов. Класс — это модель и, если местоположение не является частью этой модели, то даже самое «крайнее» расположение объектов (экземпляров этого класса) не должно иметь значение. Однако объекты существуют не в вакууме. Они взаимодействуют и обмениваются информацией с другими объектами. Если объекты (участники взаимодействия) расположены на разных компьютерах, и, возможно, даже в различных сетях, то оказывается, что фактор местоположения объектов необходимо с самого начала включать в процесс проектирования ПО. И хотя насчет того, на каком именно этапе проектирования следует рассматривать этот фактор, специалисты существенно расходятся во мнениях, тем не менее все единолушны в том, что его необходимо рассматривать. Дело в том, что обработка ошибок и исключений при взаимодействии объектов, расположенных в различных процессах или на различных компьютерах, отличается от обработки ошибок и исключений при взаимодействии объектов одного и того же процесса. Кроме того, связи и взаимодействия между объектами одного процесса реализуются совершенно не так, как при расположении объектов в различных процессах, которые могут выполняться на разных компьютерах. Это нужно иметь в виду еще на раннем этапе проектирования. В распределенном объектно-ориентированном приложении вся его работа делится между объектами и реализуется в виде функций-членов различных объектов. Объекты должны быть логически разделены согласно определенной модели декомпозиции работ (Work Breakdown Model — WBM). Они могут быть разделены согласно моделям типа «клиентс - сервер», «изготовитель-потребитель», равноправных узлов, «классной доски» или мультиагентной системы. Логическая структура каждой такой модели (с особенностями распределения объектов) показана на рис. 8.1.

Во всех моделях, показанных на рис. 8.1, предполагается, что объекты могут быть на одном и том же или на разных компьютерах (главное — они принадлежат разным процессам). Уже сам факт принадлежности рааличным процессам делает объекты распределенными [13]. Все модели представляют рааличные подходы к распределению работы приложения между объектами.

Взаимодействие между распределенными объектами

Рис.8.1. Логическая структура и распределение объектов в моделях «изготовитель-потребитель», равноправных узлов, «классной доски» и мультиагентной системы

Если объекты относятся к одному и тому же процессу, то в качестве средств межобъектно г о «общения» можно использовать механизм передачи параметров, вызовы обычных методов и использование г лобальных переменных. Если объекты принадлежат различным процессам, выполняемым на одном компьютере, то средствами ком м уникации между объекта м и м огут служить файлы, каналы, очереди c дисциплиной обслуживания «первы м пришел — первы м обслужен», разделяе м ал па м ять, буферы об м ена или пере м енные среды. Если же объекты «прописаны» на различных компьютерах, то в качестве средств связи придется использовать сокеты, вызовы удаленных процелур и дру г ие типы средств сетево г о про г раммирования. При это м мы должны поду м ать не только о то м, как булут общаться объекты в распределенном приложении, но и о том, посредство м че г о будет реализовано это об щ ение. Объектно- ориентированные приложения могут включать как простые типы данных, так и довольно сложные, а именно классы, определенные пользователем. Такие классы часто используются для связи между объектами. Поэтому связь между распределенными объектами будет обеспечиваться не только с помощью простых встроенных типов данных (например int, float или double), но и посредством классовых типов, определенных пользователем, без которых некоторые объекты не смогут выполнить свою работу. Кроме того, необходимо позаботиться о том, чтобы у одних объектов была возможность вызывать методы других объектов, расположенных в других адресных пространствах. Более того, необходимо прелусмотреть возможность для одного объекта «знать» о методах удаленных объектов. В то время как язык С++ поддерживает средства объектно-ориентированного программирования, в нем не предусмотрено никаких встроенных средств по обеспечению связи между распределенными объектами. Он не содержит никаких встроенных методов для локализации удаленных объектов и формирования к ним запросов.

Для реализации связи между распределенными объектами разработан ряд протоколов. Двумя наиболее важными из них являются IIOP (Internet Inter-ORB Protocol — протокол, определяющий передачу сообщений между сетевыми объектами по TCP/IP) и RMI (Remote Method Invocation — вызов удаленных методов). С помощью этих протоколов могут общаться объекты, расположенные практически в любом мести сети. В этой главе мы рассмотрим методы реализации распределенных объектно-ориентированных программ с использованием упомянутых протоколов и спецификации CORBA (Common Object Request BrokerArchitecture). Спецификация CORBA представляет собой промышленный стандарт для определения отношений, взаимодействий и связей между распределенными объектами. IIOP и GIOP — два основных протокола, с которыми работает спецификация CORBA. Эти протоколы хорошо согласуются с протоколом TCP/IP. CORBA — самый простой и наиболее гибкий способ добавления средств распределенного программирования в среду С++. Средства, предоставляемые спецификацией CORBA, реализуют поддержку двух основных моделей объектно-ориентированного параллелизма, которые мы используем в этой книге: «классная доска» и мультиагентные системы. Поскольку спецификация CORBA отражает принципы объектно-ориентированного программирования, с ее помощью можно реализовать приложения довольного широкого диапазона: от миниатюрных до очень больших. В этой книге мы используем MICO [14] — открытую реализацию спецификации CORBA. MICO-реализация поддерживает основные CORBA-компоненты и службы. С++ взаимодействует с MICO посредством коллекции классов и библиотек классов. Спецификация CORBA поддерживает распределенное объектно-ориентированное моделирование на каждом его уровне.

Синхронизация взаимодействия локальных и удаленных объектов

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

Обработка ошибок и исключений в распределенной среде

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

Доступ к объектам из других адресных пространств

Объекты, разделяющие одну область действия (видимости), могут взаимодействовать, получал доступ друг к другу по именам, псевдонимам или с помощью указателей. Объект доступен только в случае, если «видимо» его имя или указатель на него. Видимость имен объектов определяется областью действия. С++ рааличает четыре основ-ныхуровня областей действия:

• блока;

• функции;

• файла;

• класса.

Вспомните, что блок в С++ определяется фигурными скобками {}, поэтому присваивание значения Y переменной X в листинге 8.1 недопустимо, так как переменная Y видима только внутри блока. Функции main() неизвестно имя переменной Y за пределами блока, конец которого обозначен закрывающейся фигурной скобкой.

// Листинг 8.1. Простой пример области действия блока

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

int X; int Z; {

int Y;

Z = Y; // Вполне правомочное присваивание.

//.. .

}

X = Y ; // Неверно, поскольку имя Y уже не определено.

}

Однако имя Y видимо для любого другого кода из того же блока, в котором определена переменная Y. Имя, объявляемое внутри функции или ее объявления, получает область видимости этой функции. В листинге 8.1 переменные X и Z видимы только для функции main (), и к ним нельзя получить доступ из других функций. Понятие области видимости файла относится к исходным файлам. Поскольку С++-программа может состоять из нескольких файлов, мы можем создавать объекты, которые видимы в одном файле и невидимы в другом. Имена, обладающие областью видимости файла, видимы, начиная с местоположения их объявления и заканчивая концом исходного файла. Имена с областью видимости файла не должны объявляться ни в одной из функций. Обычно их называют глобальными переменными. Имена, которые характеризуются областью видимости объекта, видимы для любой функции-члена, объявленной как часть этого объекта. Мы используем область видимости объекта в качестве первого уровня доступа к членам объекта. Закрытый, защищенный и открытый интерфейсы объекта определяют второй уровень. И хотя само имя объекта может быть видимым, закрытые и защищенные его члены тем не менее имеют ограниченный доступ. Область действия просто сообщает нам, видимо ли имя объекта. В нераспределенной программе область действия ассоциируется с единым адресным пространством. Два объекта в одном и том же адресном пространстве могут получать доступ друг к другу по имени или указателю и взаимодействовать, просто вызывал методы друг друга.

// Листинг 8.2. Использование объектов, которые вызывают

// методы других объектов из того же

// адресного пространства

//.. .

some_object А; another_object В;

dynamic_object *C;

C = new dynamic_object;

//...

B.doSomething(A.doSomething() );

A.doSomething(B.doSomething() );

C->doMore (A.doSomething () ) ;

//...

В листинге 8.2 объекты А и В находятся в одной области видимости, т.е. объект В видим для объекта А, а объект А видим для объекта В. Объект А может вызывать функции-члены объекта В, и наоборот. А что можно сказать об областях види м ости, если два объекта находятся на различных компьютерах? Что происходит, когда объект В создается другой программой и «получает прописку» совершенно в другом адресном пространстве? Как объект А узнает о существовании объекта В и как (что особенно важно) объект А узнает имя и интерфейс объекта В? Каким образом объект А сможет вызывать функции-члены, принадлежащие объекту В, если В — часть другой программы? В листинге 8.2 объекты А и В создаются во время компиляции, а объект С — во время выполнения. Все они являются частями одной и той же программы, обладают одной областью видимости, а их адреса принадлежат адресному пространству одного и того же процесса. Чтобы процесс мог выполнить инструкцию, ему нужно знать ее адрес. При компиляции программы, представленной в листинге 8.2, адреса объектов А и В хранятся в выполняемом файле. Сле д овательно, процесс, который выполняет программу из листинга 8.2, будет знать местоположение объектов А и В. Адрес объекту С присваивается во время выполнени я программы, т.е. его точный адрес станет известен только тог д а, когда будет вызвана функция new (). Однако указатель на объект С бу д ет содержать адрес в пределах того же пространства, в котором размещаются объекты А и В, и, следовательно, процесс для получения доступа к объекту С воспользуется этим указателем. Таким образом, доступ к каждому объекту осуществляется на основе доступа к их адресам (прямого или косвенного). Имя переменной объекта — это просто псевдоним для его адреса. Если имя объекта попадает в рамки нашей области видимости, то мы можем получить к нему доступ. Проблема в том, как связать удаленный объект с нашей локальной областью видимости. Для того чтобы получить доступ к объекту D, который находится в другом адресном пространстве, нам необходим некоторый способ ввода адреса удаленного объекта в наш выполняющийся процесс, т.е. нужно научиться связывать удаленный объект с нашей локальной областью видимости. Нам требуется видимое имя, которое бы служило псевдонимом для адреса в другом процессе, причем этот процесс может выполняться даже на другом компьютере. В некоторых случалх этот самый «другой» компьютер может быть подключен к другой сети! Было бы весьма удобно запросить удаленный объект с помощью некоторого согласованного описания и получить ссылку для адреса удаленного объекта. Имея ссылку, мы могли бы взаимодействовать с этим объектом из нашей локальной области действия. Именно для таких нужд распределенного программирования и можно использовать CORBA-реализацию.

. IOR-доступ к удаленным объектам

Объектнал ссылка специального типа IOR (Interoperable Object Reference) — это стандартный формат объектной ссылки для распределенных объектов. Каждый CORBA-объект имеет IOR-ссылку. IOR-ссылка — это дескриптор, который уникально идентифицирует объект. В то время как обычный указатель содержит простой машинный адрес для объекта, IOR-ссылка может содержать номер порта, имя хоста (имя компьютера в сети), объектный ключ и пр. В С++ для доступа к динамически создаваемым объектам используется указатель. Указатель содержит информацию о том, где в памяти компьютера расположен объект. При разыменовании указателя на объект используется полученный адрес для доступа к членам этого объекта. Однако процесс разыменования указателя на объект (с целью получения доступа к нему) требует больших усилий, когда этот объект находится в другом адресном пространстве и, возможно, на другом компьютере. Указатель в этом случае должен содержать достаточно информации, чтобы сообщить точное местоположение объекта. Если объект расположен в другой сети, указатель должен содержать (прямо или косвенно) сетевой адрес, сетевой протокол, имя хоста, адрес порта, объектный ключ и физический адрес. Стандартнал IOR-ссылка действует как разновидность распределенного указателя на удаленный объект. Набор компонентов, содержащихся в IOR-ссылке под протоколом IIOP, показан на рис. 8.2.

Пон я тие переносимой (portable) объектной ссылки — это важный этап на пути к достижению распределенной обработки данных. Оно позволяет использовать локальные ссылки на удаленные объекты практически везде (в Internet или intranet) и имеет важные последствия для мультиагентных систем, в которых агентам приходится перемещаться между системами и по всему пространству Internet. Стандарт IOR создает основу для мобильных объектов и распределенных агентов. После того как ваша программа получит доступ к IOR-ссылке объекта, можно использовать брокер объектных запросов (Object Request Broker — ORB) для взаимодействия с удаленным объектом посредством вызова методов, механизма передачи параметров, возврата значений и т.п.

Логические компоненты IOR-ссылки:

Хост

Порт

Объектный ключ

Другие компоненты

Идентифицирует Internet-хост

Содержит номер порта TCP/IP, в котором целевой объект при-нимает запросы

Значение,которое однозначно преобразуется в конкретный объект

Дополнительнал информация, которую можно использовать при обращениях, например для безопасности

Рис. 8.2. Набор компонентов, содержащихся в IOR-ссылке подпротоколом IIOP

Брокеры объектных запросов (ORB)

ORB-брокер действует от имени программы. Он посылает сообщения удаленному объекту и возвращает сообщения от него. Поведение ORB-брокера можно сравнить с посредником между локальными и удаленными объектами. ORB-брокер решает все вопросы, связанные с маршрутизацией запроса от программы к удаленному объекту и с маршрутизацией ответа программе, принятого от удаленного объекта. Такое посредничество делает коммуникации между системами практически прозрачными. ORB-брокер избавляет программиста от необходимости программирования сокетов между процессами, выполняющимися на различных компьютерах. И точно так же он устраняет необходимость в программировании каналов и очередей с FIFO-дисциплиной между процессами, выполняющимися на одном компьютере. Он берет на себя немалый объем сетевого программирования, без которого не обойтись при создании распределенных программ. Более того, он стирает различия между операционными системами, языками программирования и аппаратными средствами. При программировании локальных объектов программисту больше не нужно беспокоиться о том, на каком языке реализованы удаленные объекты, на какой платформе они выполняются и к какой сети они «приписаны»: Internet или локальной intranet. ORB-брокер использует IOR-ссылки, чтобы упростить взаимодействие между компьютерами, сетями и объектами. Обратите внимание на то, что IOR-ссылка (см. рис. 8.2) содержит информацию, которая может быть использована для TCP/IP-соединений. Мы представили лишь частичное описание IOR-компонентов, поскольку IOR-дескриптор должен быть «черным ящиком» для разработчика. ORB-брокер использует IOR-ссылки, чтобы найти объект назначения. Обнаружив объект, ORB-брокер активизирует его и передает аргументы, необходимые для вызова этого объекта. ORB-брокер ожидает завершения обслуживания запроса и возвращает вызывающему объекгу ожидаемую информацию или исключение, если вызов метода оказался неудачным. Упрощенная последовательность действий, выполняемых ORB-брокером от имени локального объекта, показана на рис. 8.3.

Действия, перечисленные на рис. 8.3, представляютупро щ енную схему того, что делает ORB-брокер, взаимодействуя с удаленным объектом. Эти действия практически незаметны для локального объекта. Локальный объект вызывает один из методов удаленного объекта, а ORB-брокер делает «свою работу» от имени локального объекта. ORB-брокер выполняет большой объем обработки, заключенный всего лишь в нескольких строках кода. Обычно распределенное объектно-ориенти-рованное приложение состоит по крайней мере из двух программ. Каждая программа имеет один или несколько объектов, которые взаимодействуют друг с другом, «пересекая» адресные пространства. Характер взаимодействия объектов определяется отношениями «клиент-сервер», «изготовитель-потребитель» или базируется на принципе равноправия (модель равноправных узлов). Следовательно, если у нас есть две программы, то одна будет действовать как клиент, а другая — как сервер, или одна — как изготовитель, а другая — как потребитель, либо обе они будут равноправными. В программе 8.1 реализован потребитель, который вызывает простой удаленный объект калькулятора. На примере этой программы демонстрируется, как можно получить доступ к удаленному объекгу, а также как инициализируется и используется ORB-брокер.

УПРОЩЕННАЯ ПОСЛЕДОВАТЕЛЬНОСТЬ ДЕЙСТВИЙ ORB-БРОКЕРА ПРИ ВЫЗОВЕ МЕТОДА УДАЛЕННОГО ОБЪЕКТА _

1.   Найти удаленный объект. _

2. Активизировать модуль, содержа щ ий искомый объект, если таковой е щ е не активизирован. _

3.   Передать аргументы удаленному объекту. _

4.   Ожидать ответа после вызова метода удаленного объекта. _

5.  Вернугьлокальномуобъекту информацию или исключение, если вызовудаленного метода оказался неуспешным. _

Рис. 8.3. Упрощенная последовательность действий, выполняемых ORB-брокером от имени локального объекта

// Программа 8.1

1 using namespace std;

2 #include «adding_machine_impl.h»

3 #include <iostream>

4 #include <fstream>

5 #include <string> 6

7

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

9 {

10 CORBA::ORB_var Orb = CORBA::ORB_init(argc, argv, «mico-local-orb»);

11 CORBA::BOA_var Boa = Orb->BOA_init(argc,argv,«mico-local-boa»);

12 ifstream In(«adding_machine.objid»);

13 string Ref;

14 if('In.eof()){

15 In » Ref;

16 }

17 In.close();

18 CORBA::Object_var Obj = Orb->string_to_object(Ref.data());

19 adding_machine_var Machine =adding_machine::_narrow(Obj);

20 Machine->add(700);

21 Machine->subtract(250);

22 cout << «Результат равен " « Machine->result()« endl;

23 return(0);

24 }

25

26

При выполнении строки 10 ORB-брокер инициализируетс я. Строка 15 обеспечивает считывание из файла IOR-ссылки на объект adding_machine. Одно из прекрасных свойств IOR-ссылки состоит в том, что ее можно хранить как простую строку и передавать другим программам. Передачу IOR-ссылки проще всего реализовать с помощью аргументов командной строки, переменных среды или файлов. IOR-ссылку можно отправить по электронной почте или с помощью протокола передачи файлов (File Transfer Protocol — FTP). IOR-ссылки совместно используют файловые системы, и их можно загружать с Web-страниц. Если некоторая программа имеет IOR-ссылку на удаленный объект, то для доступа к нему можно использовать ORB-брокер. Другие методы связи между объектами с помощью IOR-ссылок будут рассмотрены ниже в этой главе. Но для начала вполне достаточно использования файловых систем. Итак, в программе 8.1 IOR-ссылка была получена путем преобразования объектной ссылки в «строковую» форму (с использованием ORB-брокера удаленного калькулятора) и записана в файл. При выполнении строки 18 локальный объект Orb преобразует «строковую» IOR-ссылку обратно в объектную. В строке 19 эта объектнал ссылка используется для реализации объекта adding_machine. Обратите внимание на то, что при вызове методов этого объекта adding_machine выполняется соответствующий код удаленного калькулятора (см. строки 20, 21 и 22).

Machine->add(700) ;

Machine->subtract(250) ;

cout « «Результат равен " « Machine->result() « endl;

И хотя вызовы этих методов сделаны в нашей локальной области види м ости, они относятся к выполняемому колу в другом адресном пространстве (в данном случае — даже к другому компьютеру). Для разработчика местоположение объекта Machine как будто перестает иметь значение. После создания (в строке 19) этот объект используется как любой другой объект С++. И хотя существуют весьма значительные различия между вызовами локальных и удаленных объектов [15], объектно-ориентированное представление, тем не менее, поддерживается, и с точки зрения объектно-ориентированного программирования удаленные объекты ведут себя как локальные. Код, представленный в программе 8.1, является кодом клиентской части приложения (или кодом «потребителя»), поскольку в нем используются возможности объекта adding_machine. Поэтому теперь (для получения завершенного приложения калькулятора) нам нужен код «ответной части», который реализует объект adding_machine. Код этого второго компонента представлен в программе 8.2.

// Программа 8.2

1 #include <iostream>

2 #include <fstream>

3 #include «adding_machine_impl.h» 4

5 6 7

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

9 {

10 CORBA::ORB_var Orb = CORBA: :ORB_init(argc,argv,«mico-local-orb»);

11 CORBA::BOA_var Boa = Orb->BOA_init(argc,argv,«mico-local-boa») ;

12 adding_machine_impl *AddingMachine =new adding_machine_impl;

13 CORBA::String_var Ref = Orb->object_to_string(AddingMachine);

14 ofstream Out(«adding_machine.objid»);

15 Out « Ref « endl;

16 Out.close() ;

17 Boa->impl_is_ready (CORBA: : ImplementationDef : :_nil () ) ;

18 Orb->run();

19 CORBA: :release(AddingMachine) ;

20 return(0);

21 } 22 23

Обратите внимание на то, что программа-«изготовитель» также должна инициализировать объект Orb (в строке 10). Это — одно из важных требований, предъявляемых к CORBA-ориентированным программам, поскольку каждая программа реализует взаимодействие с удаленными объектами с помощью ORB-брoкepa. Именно поэтому инициализация ORB-объекта— первое действие, которое должна выполнить CORBA-программа. В строке 12 объявляется реальный объект adding_machine . Это именно тот объект, с которым в действительности связывается программа 8.1. В строке 13 объектная ссылка на реальный объект adding_machine преобразуется в «строковую» форму, а затем записывается в обычный текстовый файл, чтобы ее можно было без труда прочитать. После того как IOR-ссылка записана в файл, объект Orb ожидает запроса. При каждом вызове одного из его методов этот объект выполняет соответствующее арифметическое действие (сложение или вычитание). Значение результата передается посредством вызова метода result() объекта adding_machine. Программы 8.1 и 8.2 демонстрируют базовую структуру, которую должны иметь CORBA-программы. Код, создающий объект adding_machine, начинается с объявления его CORBA-класса. Каждый CORBA-объект начинается как IDL-проект (Interface Definition Language — язык описания интерфейсов).

Язык описания интерфейсов (IDL):более «пристальный» взгляд на CORBA-объекты

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

Таблица8.1.

Ключевые слова IDL

abstract

enum

native

struct

any

factory

Object

supports

attribute

FALSE

octet

typedef

boolean

fixed

oneway

unsigned

case

float

out

union

char

in

raises

ValueBase

const

inout

readonly

valuetype

cell

interface

sequence

void

double

long

short

wchar

exception

module

string

Ключевые слова, перечисленные в табл. 8.1, представл я ют собой зарезервированные слова, используемые в CORBA-программах. Помимо определени я интерфейса функций дл я класса, я зык IDL используетс я дл я определени я отношений между к л ассами. IDL под д ерживает:

• типы, определенные пользователем;

• последовательности, определенные пользователе м;

• типы массивов;

• рекурсивные типы;

• семантику исключений;

• модули (по аналогии с пространствами имен);

• единичное и множественное наследование;

• поразрядные арифметические операторы.

Приведем IDL-определение для класса adding_machine из листинга 8.2:

interface adding_machine{

void add(in unsigned long X);

void subtract(in unsigned long X);

long result();

}

Это определение начинается с ключевого слова CORBA interface. Обратите внимание на то, что данное объявление интерфейса класса adding_machine не включает ни одной переменной, которая бы могла хранить результат выполнения операций сложения и вычитания. Методы add () и subtract () принимают в качестве параметра одно значение типа unsigned long. Объявление типа параметра сопровождается ключевым словом CORBA in, который говорит о том, что данный параметр является входным (mput). Это объявление класса хранится в отдельном исходном файле adding_machine.idl. Исходные файлы, содержащие ГОЬюпределения, должны иметь . idl-расширения. Прежде чем такой файл можно будет использовать, его необходимо преобразовать к С++чЈюрмату. Это преобразование можно выполнить с помощью препроцессора или отдельной программы. Все CORBA-реализации включают IDL-компиляторы. Существуют IDL-компиляторы лля языков С, Smalltalk, С++, Java и др. IDL-компилятор преобразует ГОЬюпределения в код соответствующего языка. В данном случае IDL-компилятор преобразует объявление интерфейса в легитимный C++-код. В зависимости от конкретной CORBA-реализации IDL-компилятор вызывается с использованием синтаксиса, который будет подобен слелующему:

idl adding_machine.idl

При выполнении этой команды создается файл, содержащий С++-код. Поскольку наше IDL-определение хранится в файле adding_machine. idl, MICO IDL-компилятор создаст файл adding_machine. h, который будет содержать несколько каркасных C++-классов и CORBA-типов данных. Базовые IDL-типы данных приведены в табл. 8.2.

Таблица 8.2. Базовые IDL -т ипы дан н ых

IDL-типы данных

Диапазон

Размер

long

1

>

_2»-2' 5 -

1

> 16 бит

0-2 v - 1

> 32 бит

IDL-типы данных

Диапазон

Размер

long

-2^31 - 2^31-1

≥ 32 бит

short

-2^15 - 2^15-1

≥ 16 бит

unsigned long

0 - 2^32-1

≥ 32 бит

unsigned short

0-2^16-1

≥ 16 бит

float

IEEE с обычной точностью

≥ 32 бит

double

IEEE с двойной точностью

≥ 64 бит

char

ISO латинский-1

≥8 бит

string

ISO латинский-1, за исключением ASCII NULL

Переменный

boolean

TRUE ИЛИ FALSE

Не определен

octet

0-255

≥8 бит

any

Произвольный тип, идентифицируемый динамически

Переменный

Даже после того как IDL-компилятор создаст из определения интерфейса С++-код, реализация методов интерфейсного класса остается все еще неопределенной. IDL-компилятор создает несколько С++-конструкций, которые предназначены для использования в качестве базовых классов. В листинге 8.3 показано два класса, сгенерированных MICO IDL-компилятором на основе файла adding_machine.idl .

// Листинг 8.3. Два класса, сгенерированные

// MICO IDL-компилятором из файла

// adding_machine.idl

class adding_machine : virtual public CORBA::Object{

public:

virtual ~adding_machine();

#ifdef HAVE_TYPEDEF_OVERLOAD

typedef adding_machine_ptr _ptr_type;

typedef adding_machine_var _var_type;

#endif

static adding_machine_ptr _narrow(CORBA::Object_ptr obj );

static adding_machine_ptr _narrow(CORBA::AbstractBase_ptr obj );

static adding_machine_ptr _duplicate(adding_machine_ptr _obj ){

CORBA::Object::_duplicate (_obj); return _obj;

}

static adding_machine_ptr _nil(){

return 0;

}

virtual void *_narrow_helper( const char *repoid );

static vector<CORBA::Narrow_proto> *_narrow_helpers;

static bool _narrow_helper2( CORBA::Object_ptr obj );

virtual void add( CORBA::ULong X ) = 0;

virtual void subtract( CORBA::ULong X ) = 0;

virtual CORBA::Long result() = 0;

protected:

adding_machine(){};

private:

adding_machine( const adding_machine& );

void operator=( const adding_machine& );

};

class adding_machine_stub : virtual public adding_machine{

public:

virtual ~adding_machine_stub();

void add( CORBA::ULong X );

void subtract( CORBA::ULong X ); CORBA::Long result();

private:

void operator=( const adding_machine_stub& );

};

Файл adding_machine.idl — это входные данные для компилятора, а файл adding_machine.h вместе с каркасны м и класса м и— результат его работы. Чтобы реализовать интерфейсы функций, объявленные в исходно м IDL-файле, разработчик использует наследование. Напри м ер, в листинге 8.4 представлен определенный пользователе м класс, который обеспечивает реализацию для одного из каркасных классов, созданных IDL-ко м пиляторо м.

// Листинг 8.4. Класс реализации структурных классов, // созданных IDL-компилятором

class adding_machine_impl : virtual public adding_machine_skel {

private:

CORBA::Long Result;

public:

adding_machine_impl (void){

Result = 0;

};

void add(CORBA::ULong X){

Result = Result + X;

};

void subtract(CORBA::ULong X){

Result = Result - X;

};

CORBA::Long result(void){

return(Result);

};

Один из каркасных файлов, созданных IDL-ко м пилятором из интерфейсного клас са adding_machine, называется adding_machine_skel. Обратите внимание на то, что при выведении новых классов IDL-компилятор берет имя из определения интерфейса. Наш класс adding_machine_impl обеспечивает реализацию интерфейса функций, объявленного с использованием языка IDL. Во-первых, в классе adding_machine_impl объявляется член данных Result. Во-вторых, здесь предлагается реализация методов add(), subtract () и result (). В то время как интерфейсный класс adding_machine включает объявление этих методов, класс adding_machine_impl обеспечивает их реализацию. Определяемый пользователем класс adding_machine_impl должен наследовать из базового класса множество функций, полезных для распределенного программирования. В этом и состоит основная схема работы, связанной с CORBA-программированием. Интерфейсный класс предназначен для представления используемых интерфейсов. Назначение IDL-компилятора ~ сгенерировать реальные каркасные С++-классы, исходя из определения интерфейса. Разработчик выводит класс из одного каркасных и обеспечивает реализацию методов, определенных в интерфейсном классе, и членов данных, которые должны использоваться для хранения атрибутов объекта. Итак, создание реальных С++-классов из IDL-определения представляет собой процесс, состоящий из трех действий.

1. Проектирование интерфейсов классов, отношений и иерархии с использование м языка IDL.

2. Использование IDL-ко м пилятора д ля генерирования реальных каркасных C++-классов на основе IDL-классов.

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

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

Анатомия базовой CORBA-программы потребителя

Одной из самых распространенных моделей для применения распределенного программирования является модель «изготовитель-потребитель». В этой модели одна программа играет роль «изготовителя», а другая — «потребителя». Изготовитель создает некоторые данные или предлагает ряд услуг, которыми пользуется потребитель (например, наша программа могла бы по требованию генерировать уникальные номерные знаки). Предположим, потребитель — это программа, которая создает запросы на новые номерные знаки, а изготовитель — это программа, которая их генерирует. Обычно потребитель и изготовитель размещаются в различных адресных пространствах. Компоненты такой программы и действия, которые должно содержать большинство CORBA-программ потребителей, представлены на рис. 8.4.

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

Рис. 8.4. Компоненты CORBA-программ потребителей и действия, которые они должны содержать

При выполнении этой инструкции ORB-oбъект инициализируется. Для ORB-объектов используется тип CORBA: :ORB_var. В CORBA-реализациях объекты, тип которых помечается суффиксом _var, берут на себя заботу об освобождении базовой ссылки (в отличие от объектов, тип которых помечается суффиксом _ptr). Аргументы командной строки передаются конструктору ORB-объекта вместе с идентификатором orb_id. В данном случае идентификатором orb_id служит строка «mico-local-orb». Строка, передаваемал функции инициализации ORB_init (), зависит от конкретной CORBA-реализации. Полученный объект называют обслуживающим ( servant object ).

После инициализации ORB-объекта и объектного адаптера разработчику CORBA-приложения необходимо позаботиться об IOR-ссылке для удаленного объекта (объектов). Как показано на рис. 8.4, IOR-ссылка считывается из файла adding_machine.ior . IOR-ссылка была записана в этот файл в строковой форме. ORB-объект используется для преобразования IOR-ссылки из строки снова в объектную форму с помощью метода string__to_object (). Как показано на рис. 8.4, это реализуется с помощью следующего вызова:

CORBA::Object_var Obj = Orb->string_to_object(Ior.c_str());

Здесь функция lor. c_str () возвра щ ает IOR-ссылку в строковой форме, а объект Obj будет содержать IOR-ссылку в объектной форме. Объектнал форма IOR-ссылки затем претерпевает процесс «сужения», который подобен операции приведения типа в С++. В результате это г о процесса объектная ссылка приводится к соответствующему типу объекта. В данном случае «соответствую щ им» является тип adding_machine. Программа-потребитель (см. рис. 8.4) сужает IOR-объект, используя следующий вызов:

adding_machine_var Machine = adding_machine::_narrow(Obj);

При выполнении этой инструкции создается ссылка на объект типа adding_machine. Программа-потребитель м ожет теперь вызывать м етоды, определенные в IDL-интерфейсе для класса adding_machine, напри м ер:

Machine->add(500);

Machine->subtract(125) ;

При выполнении этих инструкций вызываются м ето д ы add( ) и subtract () удаленного объекта. Несмотря на то что рассматриваемал программа-потребитель сильно упрощена, она дает представление о базовых компонентах типичных CORBA-программ потребителя или клиента. Однако программа-потребитель должна работать совместно с программой-изготовителем. Поэтому мы рассмотрим упрощенную CORBA-программу, которая действует как изготовитель для программы-потребителя, показанной на рис. 8.4.

Анатомия базовой CORBA-программы изготовителя

Изготовитель отвечает за обеспечение программ-потребителей данными, функциями или другими услугами. Изготовитель вместе с потребителем и составляют распределенное приложение. Каждал CORBA-программа изготовителя проектируется в расчете на существование программ-потребителей, которые булут нуждаться в предоставляемых ею услугах. Следовательно, каждая программа-изготовитель должна создавать обслуживающие объекты и IOR-ссылки, посредством которых к этим объектам можно получить доступ. На рис. 8.5 представлена простая программа-изготовитель, используемая «в содружестве» с программой-потребителем, отображенной на рис. 8.4. На рис. 8.5 также перечислены основные компоненты, которые должна содержать любая CORBA-программа изготовителя.

Обратите внимание на то, что части А обеих программ по сути одинаковы. Как потребителю, так и изготовителю требуется ORB-объект для связи друг с другом. Этот ORB-объект используется для получения ссылки на объектный адаптер. На рис. 8.5 приведен следующий вызов:

CORBA::BOA_var Boa = Orb->BOA_init(argc,argv,«mico-local-boa»);

Итак, вызов этой функции используется для получения ссылки на объектный адаптер, который служит посредником между ORB-брокером и объектом, реализующим запрашиваемые методы. Слелует иметь в виду, что CORBA-объекты должны начинаться только как объявления интерфейсов. На некотором этапе процесса разработки производный класс обеспечит реализацию CORBA-интерфейса. Объектный адаптер действует как посредник между интерфейсом, с которым связан ORB-брокер. и реальными методами, реализованными производным классом. Объектные адаптеры используются для доступа к обслуживающим объектам и объектам реализации. Изготовитель (см. рис. 8.5) создает объект реализации в части В, используя следующий вызов:

Рис. 8.5. Основные компоненты, которые должна содержать CORBA-программа изготовителя

При выполнении этой инструкции создается объект, который обеспечит реализацию услут, потенциально запрашиваемых клиентскими объектами (или потребителями). Обратите также внимание на то, что в части С (см. рис. 8.5) программа-изготовитель использует объект ORB для преобразования IOR-ссылки в строку и записывает ее в файл adding_machine.ior . Этот файл можно передать с помощью FTP-протокола, по электронной почте, посредством протокола передачи гипертекстовых файлов (HTTP) вместе с Web-страницами, с помощью сетевой файловой системы NFS и т.д. Существуют и другие способы передачи IOR-ссылок, но файловый метод — самый простой. После записи IOR-ссылки программа-изготовитель просто ожидает запросы от программ-клиентов (потребителей). Программа-изготовитель, представленная на рис. 8.5, также представляет собой упрощенный вариант CORBA-программы изготовителя (программы-сервера), тем не менее, она содержит все основные компоненты, которые должна иметь типичная программа- изготовитель.

Базовый npoeкт CORBA-приложения

Итак, из программ, представленных на рис. 8.4 и 8.5, видно, что д л я CORBA-при л ожения потребуются два ORB-объекта, объектный адаптер, метод передачи IOR-ссылки и по крайней мере один обслуживаю щ ий объект. Логическал структура CORBA-приложения показана на рис. 8.6.

После получения IOR-ссылки и приведения ее к соответствующему типу вызов удаленного метода в программе клиента (потребителя) подобен вызову обычного метода в любой С++-программе. В CORBA-примерах этой книги предполагается использование протокола IIOP (Internet Inter ORB Protocol). Поэтому ORB-брокеры (см. рис. 8.6) связываются с помощью протокола TCP/IP. IOR-ссылка должна содержать информацию о местоположении удаленного объекта, достаточную для реализации TCP/IP-связи. В качестве объектного адаптера обычно используется переносимый объектный адаптер. Но для некоторых программ (более старых и простых) можно использовать базовый объектный адаптер. Различие между этими двумя адаптерами мы рассмотрим ниже в этой главе. Каждое CORBA-приложение имеет один или несколько обслуживающих объектов, которые реализуют интерфейс, разработанный в IDL-классе. Простейшие программы потребителя и изготовителя, показанные на рис. 8.4 и 8.5, могут выполняться на одном компьютере в различных процессах или на различных компьютерах. Если эти программы выполняются на одном компьютере, файл adding_machine. ior должен быть доступен из обеих программ. Если они выполняются на различных компьютерах, этот файл должен быть послан клиентскому компьютеру по FTP-протоколу, электронной почте, HTTP-протоколу и т.д. Детали компиляции и выполнения этих программ описаны в разделах «Профиль программы 8.1» и «Профиль программы 8.2».

Рис. 8.6. Логическая структура CORBA-приложения

IDL-компилятор

IDL-компилятор представляет собой инструмент, предназначенный для перевода IDL-определений класса в С++-код. Этот код состоит из коллекции «каркасных» определений классов, перечислимых типов и шаблонных классов. Для CORBA-программ, приведенных в этой книге, в качестве IDL-компилятора используется MICO IDL-компилятор. В табл. 8.3 перечислены опции командной строки, которые чаще всего применяются при вызове этого IDL-компилятора.

Таблица 8.3. Самые распространенные опции командной строки, применяемые при вызове IDL-компилятора

• --boa  Генерирует «каркасные» конструкции, которые используют базовый объектный адаптер (basic object adapter — BOA). Эта опция испо л ьзуется по умо л чанию

• --no-boa  Отключает генерирование кода «каркасных» конструкций для BOA

• --poa  Генерирует «каркасные» конструкции, которые испо л ьзуют переносимый объектный адаптер (portable object adapter — POA)

• --no-poa  Отк л ючает генерирование кода «каркасных» конструкций для POA. Эта опция используетс я по умолчанию

• -- g en-included-defs Генерирует код, который был включен с по м о щ ью директив #include

• —version  Выводит версию спецификации MICO

• -D<define>  Опреде ля ет макрос препроцессора. Эта опци я эквивалентна ключу -D у большинства UNIX С-компиляторов

• -I<path>  Определяет путь поиска для директив #include. Эта опция эквивалентна к л ючу -I у бо л ьшинства UNIX С-компи ля торов

Ключи -boa и -poa (см. табл. 8.3) позволяют определить, на какой тип адаптера будут ориентированы создаваемые «каркасные» конструкции. Например, при выполнении слелующей команды

idl -poa -no-boa adding_machine.idl

будет получен файл adding_machine.h , который содержит «каркасные» конструкции для РОА-адаптера (portable object adapter), и будет отключено генерирование «каркасных» конструкций для ВОА-адаптера (basic object adapter).

При вводе команды idl -h будет сгенерирован полный список ключей IDL-компилятора. Если в поставке MICO надлежащим образом инсталлированы man-страницы, то ввод команды man idl обеспечит полное описание доступных IDL-ключей. Проектирование IDL-классов — первый шаг в CORBA-программировании. На слелующем этапе необходимо определить способ хранения и считывания IOR-ссылок на удаленные объекты.

Получение IOR-ссылки для удаленных объектов

ORB-класс содержит две функции-члена (string_to_object() и object_to_. string ()), которые можно использовать для преобразования IOR-объектов из строк в объекты типа Object_ptrs и обратно. Функция-член string_to_object() принимает параметр типа const char * и преобразует его в объект типа Object_ptr. Функция-член Object_to__string() принимает параметр типа Object_ptr и преобразует его в указатель типа char *. Эти методы являются составной частью интерфейса ORB-клаеса. Метод Object_to_string () используется для получения объектной IOR-ссылки строковой формы. IOR-ссылку, представленную в виде строки, можно передать программам клиентов (потребителей) различными способами, например:

• Электронная почта

• Разделяемые файловые системы (NFS-оборудование)

• FTP-протокол

• Встраивание в HTML-документы

• Java-аплеты/сервлеты

• Аргументы командной строки

• Разделяемая память

• Традиционные средства межпроцесной связи (IPC), т.е. каналы, FIFO-очереди и пр.

• Переменные среды CGI-команды приема и отправки данных

Затем программа приема данных получает строковый вариант IOR-ссылки и использует функцию-член string_to_object () ORB-объектадля преобразования IOR-ссылки в CORBA-объект ptr. Этот CORBA-объект ptr затем «сужается» (т.е. приводится к соответствующему типу) и используется для инициализации локального объекта. В программах 8.1 и 8.2 для передачи IOR-ссылки между программой-потребителем и программой-изготовителем используются строковые формы объектов и файл. Строковую форму IOR-ссылок можно использовать для обеспечения очень гибкой связи с удаленными объектами, которые могут размещаться практически в любом месте Internet, intranet или extranet. Существует реализация MIWCO (Wireless Mico) — открытая реализация спецификации wCORBA [16], стандарт беспроводной спецификации CORBA, который можно использовать для улучшения мобиль-ности объектов. Эта беспроводнал спецификация позволяет реализовать связь посредством MIOR-ссылки (Mobile IOR). Она поддерживается для TCP-, UDP- и WAP WDP-механизмов передачи (Wireless Application Protocol Wireless Datagram Protocol). Мультиагентные и распределенные агентные системы также могут воспользоваться преимуществами стандартов IOR-ссылок. IOR- и MIOR-ссылки являются частью «строительных блоков» слелующего поколения объектно-ориентированных Web-служб. Важно отметить, что хотя строковые IOR-ссылки обеспечивают гибкость и переносимость, они не могут идеально подходить ко всем ситуациям и конфигурациям. Передача файла, который содержит IOR-ссылку, — не слишком приемлемое требование для многих систем. Трудно с точки зрения практичности требовать от приложений клиента и сервера разделять одну и ту же файловую систему или сеть. А с точки зрения безопасности строковый вариант IOR-ссылки вообще исключается как достойный рассмотрения. Если приложение типа «клиент-сервер» велико по объему и достаточно разнотипно, то требование разделения строковой формы IOR<cbmKH может оказаться слишком ограничивающим. CORBA-спецификация включает еще два стандарта для получения или передачи объектных ссылок: службы имен и маклерские службы.

Служба имен

Стандарт службы имен обеспечивает механизм преобразовани я имен в объектные ссылки. Автор запроса на IOR-ссылку предоставляет в службу имен имя, а она возвращает ему объектную ссылку, соответствующую этому имени.

Служба имен действует как разновидность телефонного справочника, в котором по имени и щ ется номер. Эта служба позволяет программам клиента (потребителя) находить по имени объектные ссылки. Эту службу можно использовать не только для получения IOR-ссылок, но и для других ресурсов приложения. Получение объектной ссылки по имени называется связыванием по имени (name binding). Коллекция вариантов связывания по имени соот н осится с объектом именного контекста (naming context). Чтобы проиллюстрировать понятие именного контекста, предположим, что у нас есть приложение, которое предназначено для планировани я маршрутов и состоит из большого количества различных объектов. Мы можем организовать группы объектов в соответствии с выполняемы м и и м и функция м и. Одни объекты относятся к группе файлового ввода-вывода данных, а другие — к группе безопас н ости. Наше приложение использует также объекты, которые имеют отношение к видам транспорта: поезд, автобус, автомобиль и велосипед. Каждое такое группирование образует некоторый контекст. Например, чтобы логически сгруппировать объекты, связанные с видами транспорта, можно создать контекст транспорта и связать с ним все виды транспорта. Такое группирование позволяет сформировать именной контекст. Сначала связываем наименование каждого вида транспорта с его IOR-ссылкой. Это и есть связывание по имени. Затем соотносим это связывание по имени с контекстом транспорта. Мы используем контексты для логической организации групп связанных объектов. Коллекция связанных именных контекстов образует именной граф (naming graph). Именные контексты представляются объектами. Поскольку именной контекст реализуется как объект, он может участвовать в связывании по имени подобно любому другом)' объекту. Это означает, что именной контекст может потенциально содержать другие именные контексты. Например, на рис. 8.7 показано несколько контекстов, включающих логическое представление нашего контекста транспорта.

Обратите внимание на то, что пос л едняя строка в контексте транспорта представляет собой имя airborne (возлушный вид транспорта). Для имени airborne существует еще один контекст, именуемый flying_machines (летательные аппараты). Контекст flying_machines содержит связи с неско л ькими объектами (на основе выполняемыхфункций). Контекст transportation (транспортные средства) вместе с контекстом flying_machines образуют именной граф. На рис. 8.7 обратите внимание на то, что последний объект в контексте flying_machines называется sonic (звуковые). Имя sonic связано с контекстом fast_flying_machines. Имя sonic имеет объектную ссылку 8888. Тем самым к именному графу добавляется еще один контекст. Это — пример именного контекста, содержащего другой именной контекст. Именной граф можно использовать для представления «многоплановой» структуры взаимосвязей в распределенном объектно-ориентированном приложении. Можно сказать, что именной граф фиксирует панораму распределенного приложения. Для мультиагентных систем именной граф можно использовать в качестве разновидности семантической сети (см. § 8.1). Несмотря на то что объекты могут быть разбросаны по различным аппаратным платформам, операционным системам, языкам программирования и географически отдаленным компьютерам, именной граф может представлять единую логическую структуру взаимоотношений и связей между объектами. На рис. 8.8 показано альтернативное представление именного графа, приведенного на рис. 8.7. Именные контексты этих двух рисунков совпадают, и в обоих случаях отчетливо отображены взаимоотношения между именными контекстами. На рис. 8.8 также показано, что существует путь от контекста transportation к контексту fast_flying_machines и обратно к контексту transportation.

Для обхода именного графа в процессе решения распределенной задачи применяются известные алгоритмы обхода графов. При этом различные пути обхода именного графа могут представлять различные решения задачи. Служба имен обеспечивает автора запроса доступом к именным контекстахм и именным графам. К именным контекстам доступ осуществляется через именные графы, а к связям — через именные контексты. Связывание обеспечивает прямое соответствие имени и объектной ссылки. Рассмотрим программу 8.3, в которой представлен простой вариант «изготовителя», создающего связывание по имени и соотносящего это связывание с некоторым именным контекстом.

// Программа 8.3

1 #include <iostream>

2 #include <fstream>

3 #include «permutation_impl.h»

4 #define MICO_CONF_IMR

5 #include <CORBA-SMALL.h>

6 #include <iostream.h>

7 #include <fstream.h>

8 #include <unistd.h>

9 #include <mico/CosNaming.h> 10

11

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

13 {

14 CORBA::ORB_var Orb = CORBA: :ORB_init(argc,argv,«mico-local-orb»);

15 CORBA::Object_var PoaObj =Orb->resolve__initial_references(«RootPOA»);

16 PortableServer::POA_var Poa =PortableServer::POA::_narrow(PoaObj);

17 PortableServer::POAManager_var Mgr =Poa->the_POAManager();

18 inversion Server;

19 PortableServer: :ObjectId_var Oid =Poa->activate_object(&Server);

20 Mgr->activate () ;

21 permutation_ptr ObjectReference = Server.__this();

22 CORBA::Object_var NameService =Orb->resolve_initial_references («NameService»);

23 CosNaming: :NamingContext_var NamingContext =CosNaming::NamingContext::_narrow (NameService);

24 CosNaming: :Name name;

25 name.length (1) ;

26 name[0].id = CORBA::string_dup («Inflection»);

27 name[0].kind = CORBA::string_dup ("");

28 NamingContext->bind (name, ObjectReference);

29 Orb->run();

30 Poa->destroy(TRUE,TRUE);

31 return(0) ;

32 } 33 34

§ 8.1. Семантические сети

Семантическал сеть (semantic network) — это одна из са м ых старых и простых схе м представления зна н ий. В ос н ове се м а н тической сети лежит г рафическое изображение иерархических взаи м оот н ошений между объекта м и. На рис. 8.9 показа н а простая семантическая сеть, которая отображает зна н ия о тра н спортных средствах в цело м и о конкретных транспортных средствах в част н ости.

Рис. 8.9. Простая семантическая сеть транспортных средств

Овалы в семантической сети называются узлами, а линии — связями. Связи представляют существующие отношения между узлами. Узлы используются для представления объектов и фактов (или описателей). Некоторые связи являются дефинициональными, а другие могут быть вычислены. Связи можно использовать для отображения наследования или подчиненности. Узлы и связи вместе выражают некоторые порции знаний. Например, изучив семантическую сеть, представленную на рис. 8.9, мы понимаем, что F-15 — это транспортное средство, а также летательный аппарат, который имеет по крайней мере два крыла. Семантические сети используются для представления знаний, необходимых в ПО принятия решений.

Использование службы имен и создание именных контекстов

При выполнении строки 22 серверная про г рамма получает ссылку на службу имен

CORBA::Object_var NameService =Orb->resolve_initial_references(«NameService»);

Помимо получения объектных ссылок на хранилище реализаций (Implementation Repositoiy) и хранилище интерфейсов (Interface Repositoiy), метод ORB-объекта resolve_initial_references() используется д л я получени я ссылки на службу имен. Получив нужную ссылку, программа-сервер создает на ее основе именной контекст (см. строку 23):

CosNaming::NamingContext_var NamingContext =

CosNaming::NamingContext::_narrow(NameService);

При таком подходе мы получаем начальный именной контекст, который играет роль контекста, действующего по умолчанию. Обнаружив службу имен и создав начальный именной контекст, серверная программа может добавлять в контекст пары (связывания по имени) «имя/объектнал ссылка». Имена могут представлять собой объекты доменов или другие контексты. Чтобы добавить в контекст пару «имя/объектная ссылка», необходимо сначала создать имя. Имена реализуются в стандарте CORBA посредством структуры NameComponent.

struct NameComponent { //.. .

Istring_var id;

Istring_var kind;

}

В CORBA-реализации MICO структура NameComponent объявляется в файле CosNaming. h. Структура NameComponent содержит два атрибута: id и kind. Первый атрибут используется для хранения текста имени, а второй представляет собой идентификатор, который можно использовать для классификации объекта, например так.

//...

CosNaming::Name ObjectName;

ObjectName.length(1);

ObjectName.id = Corba::string_dup (" train») ;

ObjectName.kind=Corba::string_dup(«land_transportation»);

NamingContext->bind(ObjectName,ObjectReference) ;

//...

Здесь объяв л яется объект типа NameComponent. Атрибут id устанавливается равным значению «train», а атрибут kind— значению land_transportation. Очевидно, атрибут id до л жен быть описате л е м (дескриптором) объекта. Атрибут kind м ожно ис-пользовать для описания контекста или логической группы, к которой принадлежит этот объект. В данном случае он классифицирует поезд (train) как объект land_transportation (назе м ный вид транспорта). Метод bind () преобразует и м я объекта ObjectName в объектную ссылку ObjectReference и связывает ее с начальны м именным контексто м. И м я м ожет состоять из нескольких объектов типа NameComponent. Если имя состоит только из одного объекта типа NameComponent, оно называется простым, а если из нескольких — составным. Если имя составное, то атрибут kind можно использовать для описания отношения (этот метод рассматривается в главе 12). В программe 8.3 объект связывается с объектной ссылкой, которая соотносится с именованным контекстом. После связывания с именным контекстом объект клиента может получить доступ к контексту посредством службы имен. В программах 8.1 и 8.2 для связи (посре д ство м строковой IOR-ссылки ) между программами потребителя и изготовителя мы использовали файл. А для связи клиента и сервера (см. программу 8.3) используется служба имен.

Детали инсталляции и функционирования службы и м ен зависят от конкретной реализации. Среда MICO включает программу nsd, которая реализует COS-сов м ести м ую службу имен. Прежде чем служба имен будет доступной для программы-погребителя, необходимо залустить де м он micod и внести соответствующие элементы в хранилище реализаций. Чтобы узнать, как пользоваться програ мм а м и nsd, micod и imr, обратитесь к соответствую щ ей доку м е н тации и руководству по MICO (о н о содержит м ножество примеров использования программ imr, nsd, micod и ird). В листинге 8.5 приведен фрагмент из сценария, используемого для настройки сервера в программе 8.3, позволяющей сделать службу имен доступной для программы-потребителя.

// Листинг 8.5. Сценарий внесения записи в хранилище

// реализаций и запуска службы имен

//

micod -ORBIIOPAddr inet:hostname:portnumber —forward &

imr create NameService poa 'which nsd* IDL:omg.org/CosNaming/

NamingContext:1.0#NameService \

-ORBImplRepoAddr inet:hostname:portnumber \ -ORBNamingAddr inet:hostname:hostname:portnumberportnumber

imr create permutation persistent "'pwd'/permutation_server \ -ORBImplRepoAddr inet:hostname:portnumber \

-ORBNamingAddr inet:hostname:portnumber» IDL:permutation:1.0 \ -ORBImplRepoAddr inet:hostname:portnumber \ -ORBNamingAddr inet:hos tname:portnumber

imr activate permutation -ORBImplRepoAddr inet:hostname:portnumber \

-ORBNamingAddr inet:hostname:portnumber

Этот сценарий можно использовать в сочетании с кодом сервера, приведенным в программе 8.3. Приведенный здесь сценарий реально позволяет автоматически запустить программу-сервер permutation_server. Обратите вни м ание на то, что имена hostname и portnumber в программе 8.5 необходимо заменить реальным именем компьютера, на котором выполняется сервер, и номером порта соответственно.

Служба имен «потребитель-клиент»

Программа 8.3 связывает имя объекта с именным контекстом. Программа 8.4 содержит текст программы-потребителя, которая использует службу имен для доступа к связкам «объект-ссылка», которые были созданы в программе 8.3. Программа 8.3 генерирует перестановки любой строки символов, которую она получает. Для перестановки изменяется местоположение символов в строке. Например, эти строки

Objcte   JbOetc   tbOjec

Ojbect   JObetc

Ojbcet   JtObec

представ л яют собой перестановки строки Object. К л иент передает серверу строку и сервер генерирует N перестановок. Сервер связывает и м я «Inflection» с именным контекстом. Именно это имя программа-клиент должна задать, чтобы получить объектную ссылку из именного контекста.

// Программа 8.4

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

2 {

3

4 try{

5 CORBA::ORB_var Orb = CORBA::ORB_init(argc,argv,«mico-local-orb»);

6 object_reference Remote(«NameService»,Orb);

7 Remote.objectName(«Inflection»);

8 permutation_var Client =permutation::_narrow(Remote.objectReference());

9 char Value[1000];

strcpy(Value,«Common Object Request Broker»);

11 Client->original(Value);

12 int N;

12 for(N = 0;N < 15;N++)

14 {

15 cout « «Значение функции nextPermutation() "<< Client- >nextPermutation() « endl;

16 )

17 }

18 catch(CosNaming::NamingContext::NotFound_catch &exc) {

19 cerr << " Исключение: объект не обнаружен.» « endl;

20 }

21 catch(CosNaming::NamingContext::InvalidName_catch &exc) {

22 cerr << «Исключение: некорректное имя.» « endl;

23 }

24

25 return(0);

26 }

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

1. Получить ссылку на службу имен.

2. С помощью службы имен получить ссылку на соответствующий именной контекст.

3. С помощью именного контекста получить ссылку иа соответствующий объект.

Действие 1 реализуетс я путе м вызова м ето д а resolve_initial_references():

//.. .

CORBA::Object_var NameService;

NameService = Orb->resolve_initial_references

(«NameService»);

//...

Функция resolve_initial_references () возвратит объектную ссылку на службу имен. В действии 2 эта ссылка используетс я дл я получения объектной ссылки на именной контекст:

CosNaming: :NamingContext_var NameContext; NameContext = CosNaming::NamingContext::_narrow

(NameService);

В действии 3 значение объектной ссылки NameService «сужается», т.е. приводится к соответствую щ ему типу, в результате чего получаетс я объектнал ссылка на и м енной контекст NameContext. С по м ощью объекта NameContext програ мм а-потребитель может вызвать его м етод resolve(). Строки 24-27 из програ мм ы8.3 используютс я дл я построени я и м ени, которое и будет передано м етолу resolve ().

Name .length (1);

Name[Q].id = CORBA::string_dup («Inflection»); Name[C].kind = CORBA::string_dup (""); try {

ObjectReference = NameContext->resolve (Name);

}

Метод resolve() возвращает объектную ссылку, связанную с заданным именем объекта. В данном случае задано имя «Inflection». Обратите внимание на то, что такое же имя связывается с именным контекстом в программе8.3 (строка28). Если программа-потребитель имеет объектную ссылку, она может ее «сузить», а затем с ее помощью получить доступ к удаленному объекту. Процесс получения объектной ссылки на удаленный объект вполне тривиален, и поэтому имеет смысл его упростить путем инкапсуляции соответствующих компонентов в классе.

class object_reference{ //.. .

protected:

CORBA::Object_var NameService;

CosNaming::NamingContext_var NameContext;

CosNaming::Name Name;

CORBA::Object_var ObjectReference; public:

object_reference(char *Service,CORBA::ORB_var Orb);

CORBA::Object_var objectReference(void);

void objectName(char *FileName,CORBA::ORB_var Orb);

void objectName(char *OName); //. . . }

Про г рамма 8.4 использует преи м у щ ества просто г о каркасно г о к л асса obj ect_reference, который м ы создали с этой целью.

В про г ра мм е 8.4 (строка 6) обратите вни м ание на создание объекта Remote типа object_reference. В строке 8 этот объект используется для получения ссылки на удаленный объект с помощью следующего вызова м етода:

Remote.obj ectReference();

После этого программа-потребитель получает доступ к удаленному объекту. Класс object_reference обеспечивает выполнение некоторых необходимых действий и тем самым упрощает написание программы-потребителя. Ко н структор класса object_reference (о н вызывается в строке 6 программы 8.4) реализован следующим образом.

object_reference::object_reference(char *Service,

CORBA::ORB_var Orb)

{

NameService = Orb->resolve_initial_references (Service); NameContext = CosNaming::NamingContext::_narrow (

NameService);

}

Этот ко н структор получает ссылку на службу и м ен и создает объект к л асса NameContext. В строке 7 и м я это г о объекта передается м етолу objectName (). Затем для получения объектной ссылки, связанной с именем объекта, используется именной контекст. Метод objectName () реализован с л едую щ и м образо м.

void object_reference::objectName(char *OName) {

Name.length (1);

Name[0].id = CORBA::string_dup (OName); Name[0].kind = CORBA::string_dup ("");

try {

ObjectReference = NameContext->resolve (Name);

} catch(...) {

cerr « " Problem resolving Name " « endl; throw;

}

}

После вызова метода objectName() программа-потребитель получает доступ кссылке на удаленный объект. Теперь остается лишь вызвать метод objectReference() (это реализуется в строкев программы8.4). В методе objectName () основную часть работы выполняет функция resolve (). Программы 8.3 и 8.4 образуют простое распределенное приложение «клиент-сервер», которое для доступа к объектным ссылкам вместо строковой формы IOR-ссылок использует службу имен. В сетях intranet или Internet можно использовать оба подхода. Эти же варианты применяются в качестве опорных структурных компонентов в контексте новой модели Web-служб.

Подробнее об объектных адаптерах

Помимо службы имен и объекта именованного контекста, сервер в программе 8.3 также использует переносимый объектный адаптер. Вспомните, что адаптер (см. рис. 8.6) действует как своего рода посредник между ORB-брокером и обслуживающим объектом, который в действительности выполняет работу CORBA-объекта. Мы можем сравнить этот обслуживающий объект с «наемным» писателем, который пишет книту от имени «подуставшей» знаменитости. С этой знаменитостью наперебой общаются журналисты, литературные агенты и юристы. Знаменитость удостаивается всех почестей, но реальную работу делает за него другой человек. CORBA-объект «публикует» интерфейс с внешним миром и играет роль «знаменитости» в CORBA-программе. Программа-клиент (или потребитель) взаимодействует с интерфейсом, который обеспечивает CORBA-объект, но реальную работу выполняет обслуживающий объект, играя роль «наемного» писателя. Обслуживающий объект имеет собственный протокол, который может отличаться от используемого CORBA-объектом. CORBA-объект может предоставить С++-интерфейс для связи склиентом. Обслуживающий объект может быть реализован на Java, Smalltalk, Fortran и других языках программирования. Объектный адаптер обеспечивает интерфейс с обслуживающим объектом. Он адаптирует этот интерфейс, чтобы реализация обслуживающего объекта была прозрачна для ORB-брокера и программы-клиента. CORBA-реализация должна нормально поддерживать два типа объектных адаптеров: Basic Object Adapter (BOA) и Portable Object Adapter (POA). Сначала стандарт CORBA был ориентирован на использование ВОА-адаптера, но он не был достаточно гибким. Поэтому и был разработан РОА-адаптер, который нашел более широкое применение. ВОА-адаптер обладает минимальным набором средств, но его вполне можно использовать для активизации объектных реализаций на базе информации, которая содержится в хранилище реализаций (табл. 8.4).

Таблица 8.4. Некоторые элементы, содержащиеся в хранилище реализац и й

Имя объекта  Уникальный идентификатор для каждого объекта

Режим активации  Разделяемый, неразделяемый, постоянный, биб-

лиотека permethod

Путь  Имя или путь выполняемого файла

Список идентификаторов хранилища

ВОА-адаптер, чтобы приступить к выполнению объекта изготовителя (сервера), использует такие записи из хранилища реализаций, как режим активизации и путь. И хотя в ряде более простых примеров, приведенных в этой главе, используется ВОА-адаптер, мы рекоменлуем для серьезной CORBA-разработки применять РОА-адаптер. РОА-адаптер поддерживает:

• прозрачную активизацию объекта;

• транзитные объекты;

• не я вную активизацию обслуживаю щ их объектов;

• перманентные (постоянные) объекты за пределами сервера.

Возможно, наиболее важной функцией РОА-адаптера является взаимодействие собслуживающими объектами. CORBA-спецификация определяет обслуживающий объект следующим образом.

Обслуживающий объект — объект языка программирования, который реализует запросы к одному или нескольким объектам. Обслуживающие объекты в общем случае существуют в контексте процесса сервера. Запросы на получение объектных ссылок обслуживаются ORB-брокером, действующим в качестве связующего звена, и трансформируются в вызовы конкретных обслуживающих объектов. Во время своего жизненного цикла объект может быть связан с несколькими обслуживающими объектами.

Каждый обслуживающий объект должен иметь по крайней мере один POA-адаптер. Но возможны и другие конфигурации (рис. 8.10).

РОА-адаптерами управляют специальные объекты управления, или POA-менеджеры. CORBA-спецификация определяет РОА-менеджер таким образом:

РОА-менеджер — это объект, который инкапсулирует состояние обработки одного или нескольких РОА-адаптеров. С помощью РОА-менеджера разработчик может сделать запросы к соответствующим РОА-адаптерам с организацией очереди. Разработчик также может использовать РОА-менеджер для дезактивизации РОА-адаптеров.

Сервер в программе 8.3 служит простым примером использования объектов POA- адаптеров и РОА-менеджеров. Более подробное рассмотрение POA выходит за рамки нашей книги. За деталями обращайтесь к работе [20]. MICO-поставка также содержит ряд примеров использования мощных средств POA.

Рис.8.10. Возможные конфигурации отношений между РОА-агентами и обслуживающими объектами

Хранилища реализаций и интерфейсов

ORB-брокер для определения местоположения объектов, когда строковые IOR-ссылки недоступны, использует хранилище реализаций. Хранилища реализаций представляют собой удобное место для хранения информации, связанной со спецификой среды (например, данные о системе безопасности, детали отладки и т.д.). Хранилище реализаций должно содержать информацию, достаточную для того, чтобы ORB-брокep мог отыскать путь объекта и выполняемый файл. Утилита imr в поставке MICO используется для управления хранилищем реализаций. Она позволяет отображать записи хранилища реализаций, вносить в него новые и удалять ненужные, например:

imr create permutation persistent "'pwd' /permutation_server \ -ORBImplRepoAddr inet:hostname:portnumber \

-ORBNamingAddr inet:hostname:portnumber» IDL:permutation:1.0 \

При выполнении этой ко м анды в хранилище будет добавлена запись с перестановкой имени. Местоположение выполняе м ого файла определяется как 'pwd'/permutation_server . Эта запись также включает значения hostname и portnumber, которые сооб щ ают, где должна выполняться программа. Хранилище реализаций — весьма подходящее место для хранения информации этого типа об объекте. Эта запись также устанавливает режим активизации (persistent). ORB-брокер использует эту информацию для надлежащей инициализации выполнения программы с именем permutation_server. Полный список опций, доступных для программы imr, содержится в соответствующей документации. Помимо хранилища реализаций, используется хранилище интерфейсов, которое предназначено для хранения динамической информации о каждом объекте. Хранилище интерфейсов можно использовать для динамического определения местоположения интерфейса с CORBA-объектами. Для работы с хранилищем интерфейсов в MICO-реализациях CORBA-спецификации используется программа ird. И хотя CORBA-спецификация описывает логические возможности хранилищ реализаций и интерфейсов, все же некоторые ее детали (например, способы записи данных в хранилища и управления ими) зависят от конкретной среды, поставки и производителя.

Простые pacnpeделенные Web-службы, использующие CORBA-спецификацию

Адреса для хранилищ реализаций и служб имен можно встроить в код HTML и использовать как часть CGI-обращения к Web-серверу. Этот метод с помощью CORBA-спецификации можно применить для реализации простых распределенных Web-служб. В листинге 8.6 представлен простой HTML-код. При щелчке на гиперссылке будет выполнен CORBA-клиент. Этот CORBA-клиент может затем получить доступ к серверу, используя адрес хранилища реализаций и службы имен, который был передан в CGI-команде HTML-кода.

// Листинг 8.6. HTML-документ со встроенным обращением к // CORBA-программе (клиенту)

<HTML> <HEAD>

<TITLE> CORBA</TITLE>

</HEAD>

<BODY>

<a href=«http://www.somewhere.org/cgi-bin/client?-ORBImplRepoAddr+inet:hostname:port+-ORBNamingAddr+inet:hostname:port»>Click</a> <P>

</HTML>

Здесь клиент ссылается на программу, которая должна получить доступ к CORBA-изготовителю (серверу). У клиента есть имя объекта, с которым ему необходимо связаться, а для дальнейших действий он использует службу имен. Этот метод не требует загрузки кода на компьютер пользователя. Совсем наоборот, код клиента, выполняясь на Web-сервере, должен получить доступ к CORBA-ориентированной программе-серверу независимо от ее местоположения (или в intranet-сети, подключенной к Web-серверу, или где-нибудь в другом месте Internet). Программа-клиент должна ответить HTML-браузеру, используя соответствующий CGI-протокол. Простая конфигурация Web-служб с CORBA-компонентами показана на рис. 8.11.

Помимо протокола http, для запуска CORBA-ориентированных клиентов и серверов можно использовать сетевой теледоступ telnet. Протоколы http и telnet можно использовать для поддержки глобального распределения CORBA-компонентов. При проектировании распределенных компонентов, ориентированных на функционирование в сети Internet или intranet, важно не забывать о системе безопасности (соответствующем ПО и данных). И хотя реализации и требования, предъявляемые к безопасности, выходят за рамки этой книги, мы подчеркиваем их важную роль в любом проекте распределенной системы. Для хранения информации, имеющей отношение к безопасности, можно использовать хранилище реализаций. Любую CORBA-реализацию можно использовать в сочетании с протоколом защищенных сокетов (Secure Socket Layer — SSL) и специальной оболочкой SSH (Secure Shell).

Рис. 8.11. Простая конфигурация Web-служб с CORBA-компонентами

Маклерская служба

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

Маклер — это объект, который поддерживает маклерскую службу в распределенной среде. Его можно представить себе в виде объекта, посредством которого другие объекты могут информировать о своих возможностях и сопоставлять свои потребности с объявленными (разрекламированными) возможностями. Рекламирование возможностей или услуг называется «экспортом». Совпадение с ними потребностей или обнаружение нужных услуг называется «импортом». Экспорт и импорт позволяют динамически обнаружить необходимые услуги и реализовать позднее связывание.

И точно так же, как при связывании нескольких именных контекстов формируются именные графы, при связывании нескольких маклеров формируются маклерские графы. Именные и маклерские графы — это мощные методы представления знаний и функциональных возможностей. Именные и маклерские графы обеспечивают функционирование глобальных Web- и telnet-служб. Обход именных и маклерских графов может включать участки, которые потенциально имеют «ответвления» в какую-нибудь локальную сеть, intranet, extranet или Internet. Подобно именным контекстам маклеры обычно представляют определенные типы объектов. Например, мы могли бы позаботиться о том, чтобы маклеры одного типа имели доступ к объектам кредитных карточек, а маклеры другого — к объектам сжатия и шифрования. Можно создать маклеры, которые бы занимались объектами погоды и географии. А еще мы могли бы «научить» маклеры интересоваться финансовой деятельностью и страхованием. Объединив все эти маклеры, получим маклерский граф. Если один маклер будет работать от имени других, мы получим то, что можно назвать федерацией маклеров. Когда клиент описывает одному маклеру услуги, в которых он нуждается, а затем маклер общается со своими коллегами, чтобы найти эти услуги, то клиент и этот маклер включаются в федерацию маклеров. Это — самая мощная и гибкая форма «запроса, который не важно, где и кем будет удовлетворен». Когда федерация маклеров возвратит объектную ссылку, может оказаться, что она «родом бог-знает-откуда» и может быть реализована обслуживающим объектом (объектами), операционная система и язык программирования которого совершенно чужд программе клиента. Федерация маклеров обеспечивает доступ к очень большим и разнообразным коллекциям услуг. Следует иметь в виду, что CORBA-стандарт включает беспроводную спецификацию wCORBA, используемую для разработки мобильных агентных и мультиагентных систем. На рис. 8.12 показана базовая архитектура CORBA-ориентированного приложения типа «клиент-сервер», которое делает запросы к маклерам.

Програ мм а-клиент может взаимодействовать с маклером (или маклерами) напрямую или косвенно через федерацию маклеров. На рис. 8.12 обратите внимание на то, что после получения объектной ссылки осуществляется взаимодействие с ORB-брокером. Термины, связанные с те м ой програ мм ирования м ак л еров, приведены в таб л. 8.5.

Рис.8.12. Базовая архитектура CORBA-ориентированного приложения типа «клиент-сервер», которое делает запросы к маклерам

Таблица 8.5. Термины, связанные с темой программирования маклеров

• Экспортер  Рекламирует услугу с помощью маклера. Экспортер может быть провайдером услуг или анонсировать услугу от имени кого-то другого

• Импортер  Использует маклер для поиска услуг, соответствующих некоторому критерию. Импортер может быть потенциальным клиентом услуг или импортировать услугу от имени кого-то другого

• Предложение Содержит описание анонсируемой услуги. Описание состоит из имени-услуги и типа услуги, объектной ссылки и свойств объекта

Парадигма «клиент-сервер»

Термины «клиент» и «сервер» часто применяются к различным видам программных приложений. Парадигма «клиент-сервер» состоит в разделении работы на две части, представляемые процессами или потоками. Одна часть, клиент, создает запросы на получение данных либо действий. Другая часть, сервер, выполняет эти запросы. Роли запрашивающей и отвечающей стороны в большинстве случаев определяются логикой самих приложений. Термины «клиент-сервер» используются на уровне операционной системы для описания отношений типа «изготовитель-потребитель», которые могут существовать между процессами. Например, если для взаимодействия двух процессов используется FIFO-очередь, один из процессов «играет» роль сервера, а другой — роль клиента. Иногда клиент может «исполнить» роль сервера, если сам будет получать запросы. Аналогично сервер будет выступать в роли клиента, если ему потребуется обращаться с запросами к другим программам. Конфигурация «клиент-сервер» — основнал архитектура распределенного программирования. При этом тип сервера обычно характеризует все приложение. Некоторые наиболее популярные типы программных серверов перечислены в табл. 8.6.

Таблица 8.6. Основные типы программных серверов

• Сервер приложений Используется для обеспечения множества клиентов доступом к приложению. Вся работа приложения делится между клиентом и сервером, причем большая ее часть делается на сервере, а клиент (имея собственный процессор) выполняет только некоторую часть работы

• Файловый сервер Действует как центральное хранилище для разделяемых документов, мультимедийных файлов, баз данных и т.д. Клиенты обычно представлены терминалами или рабочими станциями в сети. Клиент делает запрос на файлы или отдельные записи в этих файлах, затем файловый сервер передает запрос к клиенту. Файловый сервер поддерживает целостность данных и безопасность доступа к файлу

• Сервер баз данных Разбивает работу приложения между различными компьютерами в сетевой среде. Клиент формирует запросы на получение некоторого элемента данных, затем сервер баз данных находит эти данные и передает запрос клиенту. Сервер баз данных может обрабатывать сложные информационные запросы, для удовлетворения которых могут понадобиться мошности нескольких баз данных

• Серверы транзакций Используется для выполнения транзакций, которые происходят на компьютере или компьютерах, содержащих сервер транзакций. Каждое действие или обновление выполняется полностью без прерывания. При возникновении некоторых проблем все действия или обновления отменяются, и делается новал попытка выполнить транзакцию

• Логические серверы Используется для решения задач, которые требуют интенсивных символьных вычислений. Логический сервер способен отыскать как неявно, так и явно заданную информацию в базе данных. Логический сервер способен проследить некоторую информацию и сделать логический вывод об информации, которая не была явно введена в базу данных. Логический сервер состоит из базы данных с одним или несколькими встроенными механизмами логического вывода. Этот механизм используется для получения заключений и выводов от сервера. База данных состоит из правил, теорем, аксиом и процедур. Чтобы удовлетворить запросы, логический сервер должен применять дедукцию, индукцию, силлогизмы и другие приемы

«Классная доска» и мультиагентные системы — это две основные архитектуры, используемые в данной книге для поддержки параллельного и распределенного программирования. Особое внимание мы уделяем логическим серверам (см. табл. 8.6). Логический сервер — это специальный тип сервера приложений, который используется для решения задач, требующих интенсивных символьных и, возможно, параллельных вычислений. Процесс формирования некоторого вывода и делукции часто тяжелым бременем ложится на процессор и может значительно выиграть от использования параллельно работающих процессоров. Обычно чем больше процессоров доступно логическим серверам, тем лучше. Мультиагентные архитектуры и архитектуры «классной доски», рассматриваемые в главах 12 и 13, опираются на понятие распределенных логических серверов, которые могут совместными усилиями решать проблемы в сетевой среде, intranet или Internet. Несмотря на то что агентный подход и стратегия «классной доски» формируют архитектуру с уклоном в сторону равноправных узлов, они являются клиентами логических серверов. Распределенные объекты используются для реализации всех компонентов системы, а CORBA-спецификация позволяет упростить сетевое программирование.

Резюме

Распре д еленное программирование включает программы, которые выполняются в различных процессах. Все процессы потенциально разме щ аются на различных компьютерах и, воз м ожно, в различных сетях с различны м и сетевы м и протокола м и. Мето д ы распре д еленного програ мм ирования позволяют разработчику раз д елить приложение на от д ельно выполняе м ые модули , отношения между которы м и м ожно определить на основе равноправия или как «изготовитель-потребитель». Каж д ый м о-луль имеет собственное а д ресное пространство и ко м пьютерные ресурсы. Распределенное програ мм ирование позволяет использовать преи м у щ ества специальных процессоров, периферийного оборудования и других ко м пьютерных ресурсов (например, серверов баз данных, приложений, почтовых серверов и т.д.). CORBA — это стандарт, применяемый для распре д еленного объектно-ориентированного программирования. В этой главе расс м атриваются только CORBA — спецификации и CORBA-службы. Здесь вы должны были получить представление об этих базовых компонентах ио том, как можно построить простую распределенную программу. CORBA-спецификации для Web-служб, MAF, службы имен можно получить по адресу: www.omg.org . За подробностями можно обратиться к книге [20]. Именные и маклерские графы обеспечивают основу для мо щ ного распределенного механизма представления знаний, который можно использовать в сочетании с мультиагентным програ м мированием. Они создают основу для следую щ его уровня интеллектуальных Web-служб.

Реализация моделей SPMD и MPMD с помощью шаблонов и MPI-программирования

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

Роджер Пенроуз (Roger Penrose), The Emperor's New Mind

Понятие параметризованного программирования поддерживается шаблонами. Основная идея параметризованного программирования — обеспечить максимально благоприятные условия для многократного использования ПО путем реализации его проектов в максимально возможной общей форме. Шаблоны функций поддерживают обобщенные абстракции процедур, а шаблоны классов — обобщенные абстракции данных. Обычно компьютерные программы уже представляют собой обобщенные решения некоторых конкретных проблем. Программа, которая суммирует два числа, обычно рассчитана на сложение любыхдвух чисел. Но если программа выполняет только операцию сложения, ее можно обобщить, «научив» выполнять идругие операции над двумя любыми числами. Если мы хотим получить самую общую программу, можем ли мы остановиться лишь на выполнении различных операций над двумя числами? А что если эти числа будут иметь различные типы, т.е. комплексные и вещественные? Можно заложить в разработку программы выполнение различных операций не только над любыми двумя числами, но и над значениями различных типов или классов чисел (например, значениями типа int, float, double или комплексными). Кроме того, мы хотели бы, чтобы наша программа выполняла любую бинарную операцию на любой паре чисел — главное, чтобы эта операция была легальна для этих двух чисел. Если мы реализуем такую программу, ее возможности в плане многократного использования будут просто грандиозными. Эту возможность С++-программисту предоставляют шаблоны функций и классов. Такого вида обобщения можно добиться с помощью параметризованного программирования.

Парадигма параметризованного программирования, полдерживаемал средствами С++, в сочетании с объектноориентированной парадигмой, также поддерживаемой средствами С++, обеспечивают уникальный подход к MPI-программированию. Как упоминалось в главе 1, MPI (Message Passing Interface — интерфейс передачи сооб щ ений) — это стандарт средств коммуникации, используемых при реализации программ, требующих параллелизма. MPI-интерфейс реализуется как коллекция, состоя щ ал более чем из 300 функций. МРI-функции охватывают большой диапазон: от порождения задач до барьер н ой синхронизации операций установки. Существует также С++-представление для MPI-функций, которые инкапсулируют функциональность MPI-интерфейса в наборе классов. Однако в библиотеке MPI не используются многие преимущества объектно ориентированной парадигмы. Преимуществ парамегризованного программирования в ней также нет. Поэтому, несмогря на то что MPI-интерфейс весьма важен как стандарт, его «мощности» не позволяют упростить параллельное программирование. Да, он действительно освобождает программиста от программирования сокетов и позволяет избежать многих ловушек сетевого программирования. Но этого недостаточно. Здесь может пригодиться кластерное программирование, а также програ мм ирование SMP-и МРР-приложений. Шаблонные и объектно-ориентированные средства программирования С++ могут оказаться весьма полезными для достижения этой цели. В этой главе для упрощения базовых SPMD- и MPMD-подходов вместе с МРI-программированием мы используем шаблоны и методы объектно-ориентированного программирования.

Декомпозиция работ для MPI-интерфейса

Одним из преимуществ использования MPI-интерфейса перед традиционными UNIX/Linux-процессами и сокетами является способность MPI-среды запускать одновременно несколько выполняемых файлов. MPI-реализация может запустить несколько выполняемых файлов, установить между ними базовые отношения и идентифицировать каждый выполняемый файл. В этой книге мы используем MPICH-реализацию MPI-интерфейса [17]1. При выполнении команды $ mpirun -np 16 /tmp/mpi_example1 будет запущено 16 процессов. Каждый процесс будет выполнять программу с именем mpi_example1. Все процессы могут использовать разные доступные процессоры. Кроме того, каждый процесс может выполняться на отдельном компьютере, если MPI работает в среде кластерного типа. Процессы при этом будут выполняться параллельно. Команда mpirun представляет собой основной сценарий, который отвечает за запуск MPI-заданий на необходимом количестве процессоров. Этот сценарий изолирует пользователя от подробностей запуска параллельных процессов на различных компьютерах. Здесь будет запущено 16 копий программы mpi_examplel. Несмотря на то что стандарт MPI-2 определяет функции порождения, которые можно использовать для динамического добавления программ к выполняемому MPI-приложению, этот метод не популярен. В общем случае необходимое количество процессов создается при запуске MPI-приложения. Следовательно, во время старта этот код тиражируется N раз. Описаннал схема легко поддерживает модель параллелизма SPMD (SIMD), поскольку одна и та же программа запускается одновременно на нескольких процессорах. Данные, с которыми каждой программе нужно работать, определяются после запуска программ. Этот метод старта одной и той же программы на нескольких процессорах можно развить, если нужно реализовать модель MPMD. Вся работа MPI-программы делится между несколькими процессами, запускаемыми на старте программы. Информация о распределении «обязанностей» (т.е. кто что делает и какие процессы работают с какими данными) содержится в самой выполняемой программе. Компьютеры, задействованные в этой работе, перечис л яются в файле machines.arch (machines.Linux в данно м случае) с использование м и м ени ко м пьютера. Местоположение это г о файла зависит от конкретной реализации. В зависи м ости от инсталляции, взаи м одействие ко м пьютеров, перечисленных в это м файле, будет обеспечено либо ко м андой ssh, либо UNIX/Linux-ко м андой ' r'.

Дифференциация задач по рангу

Во время старта процессов, включенных в MPI-приложение, МРI-среда назначает каждому процессу ранг и группу коммуникации. Ранг хранится как int-значение и служит в качестве идентификатора процесса для каждой MPI-задачи. Группа коммуникации определяет, какие процессы можно включить во взаимодействие типа «точка-точка». Сначала все MPI-процессы относят к группе, действующей по умолчанию. Заменить членов группы коммуникации можно, запустив приложения. После старта каждого процесса необходимо определить его ранг с помощью функции MPI_Comm_rank (). Функция MPI_Comm_rank () возвращает ранг вызывающего процесса. В первом аргументе, передаваемом функции, вызывающий процесс определяет, с каким коммуникатором он связывается, а его ранг возвращается во втором аргументе. Пример использования функции MPI_Comm_rank () показан в листинге 9.1.

// Листинг 9.1. Использование функции MPI_Comm_rank() //.. .

int Tag = 33;

int WorldSize;

int TaskRank;

MPI_Status Status;

MPI_Init (&argc, &argv) ;

MPI_Comm_rank(MPI_COMM_WORLD, &TaskRank) ; MPI_Comm_size(MPI_COMM_WORLD, &WorldSize) ; //.. .

Коммуникатору MPI_COMM_WORLD по умолчанию при запуске назначаются все MPI-задачи. MPI-задачи группируются по коммуникаторам, которые определяют группу коммуникации. В листинге 9.1 ранг возвращается в переменной TaskRank. Каждый процесс должен иметь уникальный ранг. После определения ранга задаче передаются соответствующие данные либо определяется код, который ей надлежит выполнить. Рассмотрим следующие варианты.

Вариант 1. Простая MPMD-модель   Вариант 2. Простая SIMD-модель

if(TaskRank == 1){   if(TaskRank == 1){

// Некоторые действия.   // Используем одни данные.

}   }

if (TaskRank == 2){   if(TaskRank == 2){

// Другие действия.   // Используем другие данные.

}   }

В первом варианте ранг используется для разграничения между процессами выполняемой работы, а во втором — для разграничения данных, которые они должны обрабатывать. Несмотря на то что каждый выполняемый MPI-файл стартует с одним и тем же кодом, модель MPMD (MIMD) можно реализовать с помощью рангов и соответствующего ветвления программы. Аналогично после определения ранга данным процесса можно назначить некоторый тип, тем самым определив конкрет-ные данные, с которыми должен работать конкретный процесс. Ранг также используется при передаче сообщений. MPI-задачи идентифицируют одна другую при обмене сообщениями по рангам и ко мм уникатора м. Функции MPI_Send () | MPI_Recv() используют ранг в качестве указания пунктов назначения и отправления соответственно. При выполнении вызова

MPI_Send(Buffer,Count, MPI_LONG, TaskRank, Tag,Comm) ;

будет отправлено Count значений типа long MPI-процессу с рангом, равным значению TaskRank. Параметр Buffer представляет собой указатель на данные, посылаемые процессу TaskRank. Параметр Count характеризует количество элементов в буфере Buffer, а не его раз м ер. Каждое сообщение имеет тег. Этот тег позволяет отличить одно сообщение от другого, сгруппировать сообщения в классы, связать определенные сообщения с определенными коммуникаторами и пр. Тег имеет тип int, а его значение определяется пользователем. Параметр Comm представляет коммуникатор, которому назначается процесс. Если ранг и коммуникатор задачи известны, этой задаче можно посылать сообщения. При выполнении вызова

MPI_Recv(Buffer, Count, MPI_INT, TaskRank, Tag, Comm, &Status);

будет получено Count значений типа int от процесса с рангом TaskRank. Инициатор вызова будет заблокирован до тех пор, пока не получит сообщение от процесса с рангом TaskRank и соответствующим значением тега (Tag). MPI-интерфейс для параметров ранга и тега поддерживает групповые символы. Такими групповыми символами являются значения MPI_ANY_TAG и MPI_ANY_SOURCE. При использовании этих значений вызывающий процесс примет следующее полученное им сообщение независимо от его источника и тега. Параметр Status имеет тип MPI_Status. Информацию об операции приема можно получить из объекта Status. Параметр статуса содержит три поля: MPI_SOURCE, MPI_TAG и MPI_ERROR. Следовательно, объект Status можно использовать для определения тега и источника процесса-отправителя. При известном количестве процессов-участников можно точно определить отправителей сообщений и их получателей. Обычно для этого используется конкретное приложение. Распределение работы также зависит от приложения. Перед началом работы каждый процесс сразу же определяет, сколько других процессов включено в приложение. Это реализуется следующим вызовом: MPI_Comm_size(MFI_COMM_WORLD, &WorldSize) ;

С помощью этой функции определяется размер группы процессов, связанных с конкретным коммуникатором. В данном используется стандартный коммуникатор (MPI_COMM_WORLD). Количество процессов-участников возвращается в параметре WorldSize. Этот параметр имеет тип int. Если каждому процессу известно значение WorldSize, значит, он знает, сколько процессов связано его коммуникатором.

Группирование задач по коммуникаторам

Процессы связываются не только с ранга м и, но и с ко мм уникатора м и. Коммуникатор определяет область коммуникации для некоторого множества процессов. Все процессы, связанные с одним и тем же коммуникатором, относятся к одной и той же группе коммуникации. Работу, выполняемую MPI-программой, можно разделить между группами коммуникаций. По умолчанию все процессы относятся к группе MPI_C0MM_WORLD. Для создания новых ко м муникаторов можно использовать функцию MPI_Comm_create (). Список функций (с краткими описаниями), используемых для работы с коммуникаторами, приведен в табл. 9.1.

Благодаря использованию рангов и коммуникаторов MPI-задачи легко идентифицировать и различать. Ранг и коммуникатор позволяют структурировать программу как SPMD- или MPMD-модель либо как некоторую их комбинацию. Для упрощения кода MPI-программы мы используем ранг и коммуникатор в сочетании с параметризованным программированием и объектно-ориентированными методами. Шаблоны можно использовать не только при м енительно к аспекту различных данных SIMD-модели, но и к заданию различных типов данных. Это значительно упрощает структуру многих приложений, требующих выполнения большого объема одинаковых вычислений, но с различными типами данных. Для реализации модели MPMD (MIMD) мы рекоменлуем использовать динамический полиморфизм (поддерживаемый объектами), параметрический полиморфизм (поддерживаемый шаблонами), объекты-функции и предикаты. Для разделения всего объема работы MPI-приложения эти методы используются в сочетании с рангами и коммуникаторами MPI-процессов. При использовании объектно-ориентированного подхода работа программы делится между семействами объектов. Все семейства объектов связываются с различными коммуникаторами. Соответствие семейств объектов различным коммуникаторам способствует модульности проекта MPI-приложения. Такой способ разделения также помогает понять, как следует применить параллелизм. Мы убедились, что объектно-ориентированный подход делает MPl-программы более открытыми для расширения, атакже простыми для поддержки, отладки и тестирования.

|Таблица 9.1. Функции, используемыедля работы с коммуникаторами

Функции

Описание

int MPI_Intercomm_create (MPI_Comm LocalComm,int LocalLeader, MPI_Comm PeerComm, int remote_leader, int MessageTag, MPI_Comm *CommOut);

Создает inter-коммуникатор из двух intra коммуникаторов

int MPI_Intercomm_merge (MPI_Comm Comm, int High,MPI_Comm *CommOut);

Создает intra-коммуникатор из inter- коммуникатора

int MPI_Cartdim_get(MPI_Comm Comm,int *NDims);

Возвращает декартову топологическую информацию, связанную с коммуникатором

int MPI_Cart_create(MPI_Comm CommOld, int NDims, int *Dims, int *Periods, int Reorder, MPI_Comm *CommCart)

Создает новый коммуникатор, к которому присоединяется топологическая информация

int MPI_Cart_sub(MPI_Comm Comm, int *RemainDims, MPI_Comm *CommNew);

Делит коммуникатор на подгруппы, которые образуют декартовы подсистемы более низкой размерности

int MPI_Cart_shift(MPI_Comm Comm, int Direction, int Display,int *Source,int *Destination);

Считывает смещенные ранги источника и приемника при заданном направлении и величине смещения

int MPI_Cart_map(MPI_Comm CommOld, int NDims, int *Dims, int *Periods, int *Newrank);

Преобразует процесс в декартову топологическую информацию

int MPI_Cart_get(MPI_Comm Comm, int MaxDims, int *Dims, int *Periods, int *Coords);

Возвращает декартову топологическую информацию, связанную с коммуникатором

int MPI_Cart_coords(MPI_Comm Comm, int Rank, int MaxDims, int *Coords);

Вычисляет координаты процесса в декартовой топологии при заданном ранге в группе

int MPI_Comm_create(MPI_Comm Comm, MPI_Group Group, MPI_Comm *CommOut) ;

Создает новый коммуникатор

int MPI_Comm_rank(MPI_Comm Comm, int *Rank ) ;

Вычисляет и возвращает ранг вызывающего процесса в коммуникаторе

int MPI_Cart_rank(MPI_Comm Comm, int *Coords, int *Rank );

Вычисляет и возвращает ранг процесса в коммуникаторе при заданном декартовом местоположении

int MPI_Comm_compare(MPI_Comm Comm1, MPI_Comm Comm2, int *Result);

Сравнивает два коммуникатора Comm1 и Comm2

int MPI_Comm_dup( MPI_Comm CommIn, MPI_Comm *CommOut) ;

Дублирует уже существующий коммуникатор со всей его кашированной информацией

int MPI_Comm_free( MPI_Comm *Comm) ;

Отмечает объект коммуникатора как освобожденный

int MPI_Comm_group( MPI_Comm Comm, MPI_Group *Group);

Получает доступ к группе, связанной с заданным коммуникатором

int MPI_Comm_size( MPI_Comm Comm, int *Size);

Вычисляет и возвращает размер группы, связанной с заданным коммуникатором

int MPI_Comm_split(MPI_Comm Comm, int Color,int Key,MPI_Comm *CommOut) ;

Создает новые коммуникаторы на основе цветов и ключей

int MPI_Comm_test_inter( MPI_Comm Comm, int *Flag);

Определяет, является ли коммуникатор inter-коммуникатором

int MPI_Comm_remote_group( MPI_Comm Comm, MPI_Group *Group);

Получает доступ к удаленной группе, связанной с заданным inter-коммуникатором

int MPI_Comm_remote_size( MPI_Comm Comm, int *Size);

Вычисляет и возвращает размер удаленной

группы, связанной с заданным inter-

коммуникатором

Анатомия MPI-задачи

На рис.9.1 представлена каркасная MPI-программа. Задачи, выполняемые этой программой, просто сообщают свои ранги MPI-задаче с нулевым рангом. Каждая MPI-программа должна иметь по крайней мере функции MPI_Init() и MPI_Finalize(). Функция MPI_Init() инициализирует MPI-среду для вызывающей задачи, а функция MPI_Finalize () освобождает ресурсы этой MPI-задачи. Каждая MPI-задача должна вызвать функцию MPI_Finalize() до своего завершения. Обратите вни м ание на обращения к функция м MPI_COMM_rank () HMPI_COMM_Size (). Они используются для получения значений ранга и количества процессов, которые принадлежат MPI-приложению. Эти функции вызываются большинством MPI-приложений. Вызов же остальных MPI-функций зависит от конкретного приложения. MPI-среда поддерживает более 300 функций (подробная информация представлена в соответствующей документации).

Рис. 9.1. MPI-программа

Использование шаблонных функций для представления MPI-задач

Шаблоны функции позволяют обоб щ ать процедуры для любо г о типа данных. Рассмотрим процедуру умножения, которая работает для любо г о типа данных (точнее, для типов данных, для которых операция умножения имеет смысл),

template<class T> T multiplies(T X, T Y) {

return( X * Y);

}

Для такой шаблонной функции, как эта, используются необходимые пара м етры дл я типа Т. Пара м етр T означает некоторый тип данных, который будет реально ***казан при реализации это г о шаблона. Так, мы можем реализовать функцию multiplies () следую щ им образом.

//. . .

multiplies<double>(3.2,4.5);

multiplies<int>(7, 2) ; multiplies<rational>(«7/2»,«3/4»); //.. .

Здесь параметр T за м еняется типо м double, int и rational соответственно, определяя тем самым точную реализацию операции умножения. Умножение д ля разных типов данных опре д еляется по-разно м у. Это означает, что д ля разных типов данных выполняется различный код. Шаблоннал функция позволяет написать одну операцию у м ножения (в виде функции multiplies ()) и при м енить ее ко м ноги м различны м типа м данных.

Реализация шаблонов и модельБРМО (типы данных)

Пара м етризованные функции м ожно использовать с MPI-интерфейсо м д ля обработки ситуаций, в которых все процессы выполняют одинаковый код, но работают с различны м и типа м и данных. Так, определив значение TaskRank процесса, м ы м о-жем распознать, с каки м и данны м и и данны м и какого типа должен работать процесс. В листинге 9.2 показано, как реализовать различные задачи д ля различных рангов.

//Листинг 9.2. Использование шаблонных функций для //   определения «фронта работ» МР1-задач

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

//.. .

int Tag = 2; int WorldSize; int TaskRank; MPI_Status Status; MPI_Init(&argc,&argv) ,-

MPI_Comm_rank (MPI_COMM_WORLD, &TaskRank) ; MPI_Comm_size (MPI_COMM_WORLD, &WorldSize) ; //.. .

switch(TaskRank) {

case 1: multiplies<double>(3.2,4.6); break;

case 2: multiplies<complex>(X,Y)

break; //case n:

//.. .

}

}

Поскольку не существует двух задач с одинаковым ранго м, все ветви в инструкции case листинга 9.2 будут выполнены различны м и MPI-задача м и. Кро м е того, такой тип параметризации м ожно распространить на контейнерные аргу м енты шаблонных функций. Это позволит передавать одной и той же шаблонной функции различные контейнеры объектов, содержащие различные типы объектов. Напри м ер, в листинге 9.3 показана обоб щ енная шаблоннал функция search ().

// Листинг 9.3. Использование контейнерных шаблонов в //   качестве аргументов шаблонных функций

template<T> bool search(T Key, graph<T>) {

//. . -

locate(Key) //. . .

}

// . . .

MPI_Comm_rank(MPI_COMM_WORLD, &TaskRank); // . . .

switch(TaskRank) {

case 1: {

graph<string> bullion;

search<string> search(«gold», bullion);

}

break; case 2: {

graph<complex> Coordinates; search<complex>((X,Y),Coordinates);

}

break;

//. . .

В листин г е 9.3 процесс, у которого TaskRank = 1, выполняет поиск в графе (graph) сименем bullion, содержа щ е м string<^beKTbi, а процесс, у которого TaskRank = 2, выполняет поиск в графе Coordinates, содержа щ е м ко м плексные числа. Мы не должны из м енять функцию search (), чтобы приспособиться к други м дан н ы м или типам данных, да и MPI-програм м а в это м случае и м еет более простую структуру, поскольку м ы м оже м м ногократно использовать шаблонную функцию поиска (search) для прос м отра контейнера graph, содержа щ его данные любого типа. Использование шаблонов значительно упро щ ает 5РМГ>програ мм ирование. Че м более об щ ей м ы делае м MPI-задачу, те м более гибкой она становится. Кро м е того, если некоторый шаблон прошел этап отладки и тестирования, надежность всех построенных на его основе МР1-задач м ожно считать довольно высокой, поскольку все они выполняют одинаковый код.

Использование полиморфизмадля реализации MPMD-модели

Полиморфиз м— одна из основных характеристик объектно-ориентированного програ мм ирования. Если язык претенлует на поддержку объектно-ориентированно г о програ мм ирования, он должен по д держивать инкапсуляцию, нас л едование и по л и м орфиз м. По л и м орфиз м — это способность объекта прини м ать м ножество форм. По л иморфизм по д держивает понятие «один интерфейс — множество реализаций • Пользователь использует одно имя, или интерфейс, реализованный различными способами и различными объекта м и. Чтобы проиллюстрировать концепцию поли м орфизма, рассмотри м класс vehicle, его пото м ков и простую функцию travel (), которая использует класс vehicle. На рис. 9.2 показана простая иерархия нашего се м ейства класса vehicle.

Рис. 9.2. Иерархия семейства класса vehicle

Самолеты, вертолеты, автомобили и подводные лодки — все это потомки класса vehicle (транспортные средства). Объект класса vehicle может заводить мотор, перемещаться вперед, поворачивать вправо, поворачивать влево, останавливаться и пр. В листинге 9.4 демонстрируется, как функция travel () использует объект класca vehicle для совершения компьютеризованного путешестви я.

// Листинг 9.4.

//Функция travel(), которая в качестве параметра использует объект класса vehicle

void travel(vehicle *Transport) {

Transport->startEngine(); Transport->moveForward() ; Transport->turnLeft();

//.. .

Transport-> stop();

}

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

//.. . car *Car;

Transportation = new Vechicle(); travel(Car); //.. .

}

Функция travel () принимает указатель на объект класса vehicle и вызывает методы объекта класса vehicle. Обратите внимание на то, что функция main() в листинге 9.4 объявляет объект типа саг, а не vehicle, а также на то, что функции travel () вместо объекта типа vehicle передается объект типа car. Это возможно благодаря тому, что в С++ указатель на класс может ссылаться на объект этого типа или на любой объект, который является потомком этого типа. Поскольку класс саг является производным от класса vehicle, то указатель на тип vehicle может ссылаться на объект типа саг. Функция travel () написана без учета того, какими конкретно типами vehicle- объектов она будет манипулировать. Для функции travel () вполне достаточно, чтобы ее vehicle -объекты могли запускать мотор, двигаться вперед, поворачивать влево, вправо и т.д. Если vehicle -объект способен выполнять эти действия, то функция travel () сможет справиться со своей работой. Обратите внимание на то, что на рис. 9.2 методы класса vehicle объявлены как виртуальные (virtual). Объявление методов виртуальными в базовом классе является необходимым условием динамического полиморфизма. В каждом из классов car, helicopter, submarine и airplane будут определены следующие функции.

startEngine(); moveForward(); turnLeft(); turnRight(); stop(); //.. .

При этом объявление каждой функции будет соответствовать типу транспортного средства. Несмотря на то что транспортное средство каждого типа способно двигаться вперед, метод, в котором обеспечивается движение автомобиля, отличается от метода перемещения подводной лодки. Управление поворотом вправо у самолета отличается от управления таким же поворотом у автомобиля. Следовательно, транспорт-ное средство каждого типа должно реализовать необходимые операции для получения законченного описания «своего» класса. Поскольку эти операции объявляются как виртуальные в базовом классе, они и являются кандидатами для реализации полиморфизма. Если vehicle -указатель, переданный функции travel (), в действительности ссылается на объект типа car, то методами, вызываемыми в этой функции (startEngine (), moveForward() и пр.), реально окажутся те, которые определены в классе car. Если vehicle -указатель, переданный функции travel (), вдействительности ссылается на объект класса airplane, то методами, вызываемыми в этой функции, реально окажутся те, которые определены в классе airplane. Это и есть тот случай, когда много форм реализуется при одном интерфейсе. Несмотря на то что функция travel () вызывает только один набор методов, поведе н ие этих м етодов может радикаль н о отличаться в зависи м ости от то г о, указатель на объект како г о vehicle -класса был назначен vehicle -указателю. По л и м орфиз м фу н кции travel () состоит в то м, что при каждо м вызове о н а м ожет выпо лн ять соверше нн о раз н ые действия. И в самом де л е, поско л ьку фу н кция travel () испо л ьзует указате л ь на к л асс vehicle, в булу щ ем ее можно испо л ьзовать д л я типов, производных от к л асса vehicle, которые бы л и неизвестны и л и не су щ ествовали во время разработки функции travel(). До тех пор пока буду щ ие vehicle -к л ассы будут нас л едовать к л асс vehicle и опреде л ять необходимые методы, ими можно будет управ л ять с помо щ ью фу н кции travel (). Этот тип по л иморфизма называется динамическим (runtime polymorphism), поско л ьку фу н кция travel () н е знает точно, какие и м енно функции startEngine (), moveForward( ) и л и turnLeft () она будет вызывать, до тех пор, пока про г ра мм а не начнет выпо л няться.

Этот тип полиморфиз м а полезен при реализации MPI-програ мм, которые используют модель MPMD. Если MPI-задачи работают с указател ям и на базовые классы, то полиморфиз м позволяет MPI-классу также работать с любы м и класса м и, производными от не г о. Предположи м, что в м есто объявления с указателе м функция travel () (см. листин г 9.4) имела бы такое объявление: void travel(vehicle Transport);

В этом случае при обра щ ении к функциям startEngine (), moveForward () и прочим вызывались бы м етоды, принадлежа щ ие только классу vehicle, и обращение к производным классам было пробле м атичны м. Использование же указателя на класс vehicle и объявления м етодов в классе vehicle виртуальны м и (virtual) заставляют работать м еханиз м поли м орфиз м а. MPI-задачи, которые м анипулируют указателями на базовые классы, мо г ут точно так же использовать преиму щ ества полиморфизма, как функции travel () удается работать с любым типом vehicle-объекта (настоя щ и м или булу щ им). Этот метод открывает большие перспективы дл я булу щ е г о кластерных приложений, а также приложений SMP (Symmetrical Multiprocessing — симметричнал мно г опроцессорнал обработка) и MPP (Massively Parallel Processing — массовал параллельнал обработка), в которых необходимо реализовать модели MPMD. Чтобы понять, как модель MPMD работает в MPI-контексте, попробуем использовать нашу функцию travel () в качестве МРТзадачи, которая является частью подсистемы поиска. Все MPI-задачи отвечают за выполнение поисково-спасательных операций применительно к vehicle-объектам различного типа. Очевидно, что каждое транспортное средство (vehicle-объект) характеризуется рааличными способами движения. Несмотря на то что проблема, стоя щ ал перед всеми MPI-задачами, заключается в выполнении поиска, все они будут иметь различные коды, поскольку все эти задачи используют различные виды vehicle-объектов, которые работают по-разно м у и требуют различных данных. Код, который содержится в листинге 9.5, необходимо запустить в нашей среде MPICH с по м о щ ью слелую щ ей ко м анды.

$ mpirun -np 16 /trap/search_n_rescue

// Листинг 9.5. Реализация MPI-задачами простого

// поиска и имитации спасения поврежденных

// объектов

template<T> bool travel(vehicle *Transport,

set<T> Location, T Object)

{

//.. .

Transport->startEngine(); Transport->moveForward(XDegrees); Transport->turnLeft(YDegrees); //.. .

if (Location.find(Transport->location() == Object){ // . .. rescue()

}

//.. .

}

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

326 Глава 9. Реализация моделей SPMD и MPMD с помощью шаблонов..

{

//...

int Tag = 2; int WorldSize; int TaskRank; MPI_Status Status; MPI_Init(&argc,&argv);

MPI_Comm_rank(MPI_COMM_WORLD, &TaskRank); MPI_Comm_size(MPI_COMM_WORLD, &WorldSize); //. . .

switch(TaskRank) {

case 1: {

//. . .

car * Car;

set<streets> SearchSpace

travel<streets>(Car, SearchSpace,Street); //.. .

}

break;

case 2:

{

//.. .

helicopter *BlueThunder; set<air_space> NationalAirSpace; travel<air_space>(BlueThunder,

NationalAirSpace,

AirSpace);

//.. .

}

//case n: //. . .

}

}

Программа search_n_rescue будет запущена в 16 процессах, причем все процессы потенциально могут выполняться на различных процессорах, а все процессоры — находиться на различных компьютерах. Несмотря на то что все процессы выполняют один и тот же код, их действия могут радикально различаться (как и данные, с которыми они работают). Шаблоны и полиморфизм позволяют отличать одну MPI-задалу от другой (а значит, и данные, которые они будут использовать). Обратите внимание на то, что в листи н ге 9.5 МРI - процесс, у которого TaskRank = 1, будет использовать объект класca Car и контейнер, содержа щ ий streets - объекты . MPI-процесс, у которо г о TaskRank = 2, будет использовать объект класса helicopter и аir_spасе объекты. Обе задачи вызывают шаблонную функцию travel (). Поскольку шаблоннал функция travel () манилулирует указателями на класс vehicle, она может воспользоваться преимущест-вами полиморфизма и выполнять операции с потомками класса vehicle. Это означает, что, хотя все MPI-задачи вызывают одну и гу же функцию travel (), действия, вы полняемые этой функцией, рааличны. Обратите внимание на то, что в функции travel () нет инструкций case или if, которые бы пытались идентифицировать тип vehicle -объекта, с которым она работает. Конкретный vehicle -объект определяется типом, на который используется указатель. Это MPI-приложение может работать потенциально с 16 различными транспортными средствами, каждое из которых характеризуется собственным типом мобильности и областью поиска. Существуют и другие методы, которые можно использовать для реализации модели MPMD в среде MPI, но полиморфический подход обычно требует меньшего объема кода.

Основные два типа полиморфизма, которые мы здесь демонстрируем, — это полиморфизм динамического связывания, по д держиваемый наследованием и виртуальными методами, и параметрический полиморфизм, по д держиваемый шаблонами. Функция travel () в листин г е 9.5 использует оба типа полиморфизма. Полиморфизм, основанный на наследовании, характеризует параметр vehicle *Transport, а параметрический полиморфизм — параметры set<T> и T Object. Параметрический полиморфизм представляет собой механизм, благодаря которому один и тот же код используется для различных типов, передаваемых в качестве параметров. Различные типы полиморфизма, которые позволяют упростить МРТзадачи и сократить код, необходимый для реализации MPI-программы, перечислены в табл. 9.2.

Таблица 9.2. Различные типы полиморфизма, которые можно использовать  для упрощения МРI-задач

Типы полиморфизма

Механизмы

Описание

Динамический

Наследование и виртуальные методы

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

Параметрический

Шаблоны

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

Введение MPMD-модели c помощью функций -объектов

Функции-объекты используются в стандартных алгоритмах для реализации горизонтального полиморфизма. Полиморфизм, реализованный с помощью передачи параметра vehicle *Transport в листинге 9.5, является вертикальным, поскольку для функционирования необходимо, чтобы классы были связаны наследованием. При горизонтальном полиморфизме классы связаны не наследованием, а интерфейсом. Все функции-объекты определяют операторную функцию operator (). Функции-объекты позволяют разрабатывать MPI-задачи с использованием некоторой общей формы.

// Функция-объект class some_class{ //.. .

operator(); //

};

template<class T> T mpiTask(T X) {

//

Т Result; Result = X() //. . .

}

Шаблонная функция mpiTask () будет работать с любым типом T, который имеет соответствующим образом определенную функцию operator ().

//. . .

MPI_Init(&argc, &argv);

MPI_Comm_rank(MPI_COMM_WORLD, &TaskRank); MPI_Comm_size(MPI_COMM_WORLD, &WorldSize); //. . .

if(TaskRank == 0){ //. . .

user_defined_type M; mpiTask(M); //.. .

}

if(TaskRank == N){ //.. .

some_other_userdefined_type N; mpiTask (N) ;

}

//----

Этот горизонтальный полиморфизм не имеет отношения к наследованию или виртуальным функциям. Поэтому, если наша MPI-задача получит свой ранг, а затем объявит тип объекта, в котором определена функция operator (), то при вызове функции mpiTask () ее поведение будет продиктовано содержимым метода operator (). Тогда, несмотря на идентичность всех процессов, запу щ енных посредством сценария mpirun, полиморфизм шаблонов и функций-объектов позволит всем MPI-задачам выполнять различную работу над различными данными.

Как упростить взаимодействие между MPI-задачами

Помимо упрощения и сокращения размеров кода МРТзадачи с помощью полиморфизма и шаблонов, мы можем также упростить взаимодействие между MPI-задачами, воспользовавшись преимуществами перегрузки операторов. Функции MPI_Send () и MPI_Recv () имеют следующий формат:

MPI_Send(Buffer, Count, MPI_LONG, TaskRank, Tag, Comm);

MPI_Recv(Buffer,Count,MPI_INT, TaskRank, Tag, Comm, &Status);

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

Таблица 9.3 Прототипы MPI-функций отправки и приема данных

Функции Описание

#include «mpi.h»

int MPI_Send (void *Buffer,int Count, MPI_Datatype Туре, int Destination, int MessageTag, MPI_Comm Comm) ; Выполняет базовую отправку данных

int MPI_Send_init (void *Buffer,int Count, MPI_Datatype Type, int Destination, int MessageTag, MPI_Comm Comm, MPI_Request *Request); Инициализирует дескриптор для стандартной отправки данных

int MPI_Ssend (void *Buffer,int Count, MPI_Datatype Type, int Destination, int MessageTag, MPI_Comm Comm); Выполняет базовую отправку данных с синхронизацией

int MPI_Ssend_init (void *Buffer,int Count, MPI_Datatype Type, int Destination, int MessageTag, MPI_Comm Comm, MPI_Request *Request); Инициализирует дескриптор для стандартной отправки данных с синхронизацией

int MPI_Rsend (void *Buffer,int Count, MPI_Datatype Type, int Destination, int MessageTag, MPI_Comm Comm) ; Выполняет базовую отправкуданных с сигналом готовности

int MPI_Rsend_init (void *Buffer,int Count, MPI_Datatype Type, int Destination, int MessageTag, MPI_Comm Comm, MPI_Request *Request); Инициализирует дескриптор для стандартной отправки данных с сигналом готовности

int MPI_Isend (void *Buffer,int Count, MPI_Datatype Type, int Destination, int MessageTag, MPI_Comm Comm, MPI_Request *Request ); Запускает отправку без блокировки

int MPI_Issend (void *Buffer,int Count, MPI_Datatype Туре, int Destination, int MessageTag, MPI_Comm Comm, MPI_Request *Request); Запускает синхронную отправку без блокировки

int MPI_Irsend (void *Buffer,int Count, MPI_Datatype Туре, int Destination, int MessageTag, MPI_Comm Comm, MPI_Request *Request); Запускает неблокирующую отправкуданных с сигналом готовности

int MPI_Recv (void *Buffer,int Count, MPI__Datatype Type, int source, int MessageTag, MPI_Comm Comm, MPI_Status *Status); Выполняет базовый прием данных

int MPI_Recv_init (void *Buffer,int Count, MPI_Datatype Type, int source, int MessageTag, MPI_Comm Comm, MPI_Request *Request); Инициализирует дескриптор для приема данных

int MPI_Irecv (void *Buffer,int Count, MPI_Datatype Type, int source, int MessageTag, MPI_Comm Comm, MPI_Request *Request); Запускает прием данных без блокировки

int MPI_Sendrecv (void *sendBuffer, int SendCount, MPI_Datatype SendType, int Destination, int SendTag, void *recvBuffer, int RecvCount, MPI_Datatype RecvYype, int Source, int RecvTag, MPI_Comm Comm, MPI_Status *Status); Отправляет и принимает сообщение

int MPI_Sendrecv_replace (void *Buffer,int Count, MPI_Datatype Туре, int Destination, int SendTag,int Source,int RecvTag, MPI_Comm Comm, MPI_Status *Status); Отправляет и принимает сообщение с использованием единого буфера

Наша цель — обеспечить отправку и получение MPI-данных с помо щ ью потоково г о представления iostream-классов. Данные удобно отправлять, используя следую щ ий синтаксис.

//...

int X; float Y;

user_defined_type Z;

cout « X << Y « Z;

//...

Здесь разработчик не должен указывать типы данных при вставке их в объект cout. Для вывода этих данных трех типов достаточно определить оператор "<<". Анало г ично можно поступить при выделении данных из потоково г о объекта cin.

//...

int X; float Y;

user_defined_type Z;

cin >> X >> Y >> Z;

//...

В инструкции ввода данных их типы не задаются. Перегрузка операторов позволяет разработчику использовать этот метод для MPI-задач. Поток cout реализуется из класса ostream, а поток cin — из класса istream. В этих классах определены операторы "<<" и ">>" для встроенных С++-типов данных. Например, класс ostream содержит ряд перегруженных операторных функций "<<".

//.. .

ostream& operator<<(char с);

ostream& operator<<(unsigned char с);

ostream& operator<<(signed char с);

ostream& operator<<(const char *s);

ostream& operator<<(const unsigned char *s);

ostream& operator<<(const signed char *s);

ostream& operator<<(const void *p);

ostream& operator<<(int n);

ostream& operator<<(unsigned int n);

ostream& operator<<(long n);

ostream& operator<<(unsigned long n);

//.. .

С помощью этих определений пользователь классов ostream и istream применяет объекты cout и cin, не указывал типы передаваемых данных. Этот метод перегрузки можно использовать для упрощения МРI- взаимодействия. Мы рассмотрели идею PVM-потока в главе 6. Здесь мы применяем тот же подход к созданию MPI-потока, используя структуру классов istream и ostream в качестве руководства для разработки класса mpi_stream. Потоковые классы состоят из компонентов состояния, буфера и преобразования. Компонент состояния представлен классом ios; компонент буфера — классами streambuf, stringbuf или filebuf. Компонент преобразования обслуживается классами istream, ostream, istringstream, ostringstream, ifstream и ofstream. Компонент состояния отвечает за инкапсуляцию состояния потока. Класс ios включает формат потока, информацию о состоянии (работоспособное или состояние отказа), факт достижения конца файла (eof). Компонент буфера используется для хранения считываемых или записываемых данных. Классы преобразования предназначены для перевода данных встроенных типов в потоки байтов и обратно. UML-диаграмма семейства классов iostream показана на рис. 9.3.

Рис. 9.3. UML-диаграмма семейства классов iostream

Перегрузка операторов «<<» и «>>» для организации взаимодействия между MPI-задачами

Взаимоотношения и функциональность классов, показанных на рис. 9.3, можно использовать как своего рода образец для проектирования класса mpi_streams. И хотя проектирование потоковых MPI-классов требует больше предварительной работы по сравнению с непосредственны м использование м функций MPI_Recv () HMPI_Send() , в целом оно делает MPI-разработку значительно проще. А если программы с параллельной обработкой можно упростить, это нужно сделать обязательно. Уменьшение сложности программ — весьма достойнал цель для программиста. Здесь мы представляем лишь каркас класса mpi_stream. Но этого вполне достаточно для получения понятия о конструкции потокового MPI-класса. После разработки класса mpi_stream можно приступать к упрощению организации взаимодействия между MPI-задачами в большинстве MPI-программ. Листинг 9.6 содержит фрагмент из объявления класса mpi_stream.

// Листинг 9.6. Фрагмент объявления

// класса mpi_stream

class mpios{ protected:

int Rank;

int Tag;

MPI_Comm Comm;

MPI_Status Status;

int BufferCount;

//.- . public:

int tag(void);

//...

}

class mpi_stream public mpios{ protected:

mpi_buffer Buffer;

//.. .

public: //.. .

mpi_stream(void) ;

mpi_stream(int R,int T,MPI_Comm С);

void rank(int R);

void tag(int T);

void comm(MPI_Comm С);

mpi_stream &operator<<(int X);

mpi_stream &operator<<(float X);

mpi_stream &operator<<(string X);

mpi_stream &operator<<(vector<long> &X);

mpi_stream &operator<<(vector<int> &X),

mpi_stream &operator<<(vector<float> &X);

mpi_stream &operator<<(vector<string> &X);

mpi_stream &operator>>(int &X);

mpi_stream &operator>>(float &X);

mpi_stream &operator>>(string &X);

mpi_stream &operator>>(vector<long> &X);

mpi_stream &operator>>(vector<int> &X);

mpi_stream &operator>>(vector<float> &X);

mpi_stream &operator>>(vector<string> &X);

//. . .

};

Для того чтобы сократить описание, мы объединили классы impi _stream и ompi _stream в единый класс mpi _stream. И точно так же, как классы istream и ostream перегружают операторы "<<" и ">>", мы обеспечим их перегрузку в классе mpi_stream. В листинге 9.7 показано, как можно определить эти перегруженные операторы:

// Листинг 9.7. Определение операторов   и **»*

//. . .

mpi_stream &operator<<(string X) {

MPI_Send(const_cast<char*>(X.data()),X.size(),

MPI__CHAR, Rank, Tag, Comm) ; return(*this);

}

// Упрощенное управление буфером, mpi_stream &operator<<(vector<long> &X) {

long *Buffer;

Buffer = new long[X.size()]; copy(X.begin(),X.end(),Buffer);

MPI_Send(Buffer,X.size(),MPI_LONG,Rank,Tag,Comm); delete Buffer; return(*this);

}

// Упрощенное управление буфером, mpi_stream &operator>>(string &X) {

char Buffer[10000];

MPI_Recv(Buffer,10000,MPI_CHAR,Rank,Tag,Comm, &Status); MPI_Get_count(&Status,MPI_CHAR,&BufferCount); X.append(Buffer); return(*this);

}

Назначение класса mpios в листинге 9.7 такое же, как у класса ios в семействе классов iostream, а именно: поддерживать состояние класса mpi_stream. Все типы данных, которые должны использоваться в ваших MPI-приложениях, должны иметь операторы "<<" и ">>", перегруженные с учетом каждого типа данных. Здесь мы продемонстрируем несколько простых перегруженных операторов. В каждом случае мы представляем упро щ енный вариант управления буфером. На практике необходимо прелусмотреть обработку исключений (на базе шаблонных классов) и распределение памяти (на базе классов-распределителей ресурсов). В листинге 9.7 обратите внимание на то, что класс mpios содержит коммуникатор, статус класса mpi_stream, номер буфера и значение ранга или тега (это — лишь одна из возможных конфигураций класса mpi_stream— существует множество других). После того как класс mpi_stream определен, его можно использовать в любой MPI-программе. Взаимодействие между MPI-задачами может быть организовано следую щ им образом.

//. . .

int X; float Y;

vector<float> Z;

mpi_s tream S tream (Rank, Tag, MPI_WORLD_COMM) ;

Stream « X << Z; Stream << Y;

//...

Stream >> Z;

Такой подход позволяет программисту, поддерживал потоковое пре д ставление, упростить МРТко д. Безусловно, в опре д еление операторов "<<" и ">>" необходимо включить соответствующую проверку ошибок и обработку исключительных ситуаций.

Резюме

Реализация SPMD- и MPMD-моделей параллелизма во многом выигрывает от использования шаблонов и механизма полиморфизма. Несмотря на то что MPT интерфейс включает средства динамического С++-связывания, в нем не используются преимущества методов объектно-ориентированного программирования. Это создает определенные трудности для разработчиков, использующих стандарт MPI. Для упрощения MPMD-программирования можно успешно использовать такие свойства объ-ектноориентированного программирования, как наследование и полиморфизм. Параметризованное программирование, которое поддерживается с помощью C++-шаблонов, позволяет упростить SPMD-программирование MPI-задач. Разделение работы программы между объектами — это естественный способ реализовать параллелизм в приложении. Для того чтобы облегчить взаимодействие между группами объектов, характеризующимися различной степенью ответственности за выполняемую работу, семейства объектов в MPI-приложении можно связать с коммуникаторами. Для поддержки потокового представления используется перегрузка операторов. Применение методов объектно-ориентированного и параметризованного программирования в рамках одного и того же MPI-приложения является воплощением муль-типарадигматического подхода, который упрощает код и во многих случалх уменьшает его объем. Тем самым упрощается отладка программ, их тестирование и поддержка. МРТзадачи, реализованные с помощью шаблонных функций, характеризуются более высокой надежностью при использовании различных типов данных, чем отдельно определенные функции с последующим обязательным выполнением операции приведения типа.

Визуализация проектов параллельных и распределенных систем

Мысл и, н е оформле нн ые в словес н ую о б олочку, — это впол н е обыч н ое явле ни е. Наш и и де и часто воз ни каю т н а уров н е ощуще нии. Мы вдруг нач ин аем чувс т вова т ь прав и ль н ос т ь реше ни я проблем, н ад ко т орым и б и л и сь долгое время, и т олько по т ом решаемся о б оз н ач ит ь и х н а т ом и л и ин ом языке... Оче н ь м н ого и дей пр и ходя т н ам в головы в бессловес н ой форме...

О. Коэхлер (О. Koehler), The Ability of Birds to Count

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

Унифицированный язык моделирования (Uniflted Modeling Language — UML) содержит графические средства, используемые для проектирования, визуализации, моделирования и документирования артефактов системы программного обеспечения. Язык UML представляет собой фактический стандарт для моделирования объект-нсюриентированных систем. Этот язык использует символы и условные знаки для обозначения артефактов системы ПО, отображаемых с различных точек зрения и при различной фокусировке. Язык UML вобрал в себя методы объектно-ориентирован-ного анализа и проектирования, предложенные Гради Бучем (GradyBooch), Джеймсом Рамбау Qames Rumbaugh) и Айваром Джекобсоном (Ivar Jacobson) в 1980-х и 1990-х годах. Он был принят рабочей группой по развитию стандартов объектного программирования (Object Management Group — OMG), международной организацией, состоящей из разработчиков ПО и производителей информационных систем и насчитывающей более 800 членов. Принятие UML дало разработчикам ПО не просто единый язык, а инструмент для анализа объектов, их описания, визуализации и документирования.

В этой главе мы покажем, как можно визуализировать и смоделировать параллельную и распределенную систему с помощью UML. Помимо помощи в разработке системы, моделирование позволяет идентифицировать области параллелизма (где именно?), понять необходимость применения синхронизации и взаимодействия подсистем (когда именно?), а также продумать степень распределения объектов (как именно?). Мы рассматриваем диаграммные методы визуализации и моделирования параллельных систем со структурной и поведенческой точек зрения. Однако следует отметить, что классы, объекты и системы, используемые в этой главе как примеры, служат целям демонстрации и необязательно отражают реальные классы, объекты или структуры, используемые в действительно существующей системе.

Визуализация структур

При рассмотрении системы со структурной точки зрения акцент ставится на ее статических частях, т.е. нас интересует, как построены элементы системы. В этом случае изучаются атрибуты, свойства и операции, выполняемые системой, а также ее организация, устройство (состав компонентов) и взаимоотношение элементов в системе. В этом разделе рассматриваются диаграммные методы, используемые для моделирования:

• классов, объектов, шаблонов, процессов и потоков;

• организации объектов, работающих «в одной команде».

Изображаемые при моделировании системы элементы могут быть концептуальными или физическими.

Классы и объекты

Класс — это м о д ель некоторой конструкции, характеризую щ ейся опре д еленными атрибута м и и пове д ение м. Это — описание м ножества понятий или объектов, которые обладают об щ и м и атрибута м и. Класс — это базовый ко м понент любо й объектно-ориентированно й систе м ы. Классы м ожно и спользовать д ля пре д ставления реальных, концептуальных, аппаратных и про г ра мм ных конструкци й. Для пре д ставления классов, объектов и взаи м оотношений, которые су щ ествуют между ни м и в параллельной и/или распределенной систе м е, используется диаграмма класса (class diagram). Диа г ра м ма класса позволяет отобразить атрибуты и услу г и, предоставляе м ые классом, а также о г раничения, нала г ае м ые на способ связи этих классов/объектов.

Язык UML содержит средства для графического представления класса. Для простейшего изображения класса достаточно начертить прямоугольник и написать на нем имя класса. При использовании только одного имени говорят, что это простое гшя. С помощью диаграммы класса можно также отобразить атрибуты и услуги. предоставляемые пользователю этого класса (или операции, выполняемые этим классом). Чтобы включить в диаграмму атрибуты и операции, прямоугольник отображается с тремя горизонтальными отделениями. В верхнем отделении записывается простое имя класса, в среднем — атрибуты, а в нижнем — операции. Разделы атрибутов и операций можно пометить словами «атрибуты» и «операции» соответственно. Имя класса должно быть указано в любом случае, а раздел атрибутов или операций — по необходимости. Это значит, что если нужно указать один из разделов (атрибутов или операций), то другой отображается пустым. Различные способы представления класса показаны на рис. 10.1.

Рис. 10.1. Различные способы представления класса

На рис. 10.1 представ л ен к л асс student_schedule. На рис. 10.1, а) показано его простейшее представление, рис. 10.1, б) содержит полную информацию о классе: его имя, атрибуты и операции, а рис. 10.1, в) представляет имя класса и его операции (раздел, который должен содержать атрибуты, пуст). Если раздел атрибутов оставлен пустым, это означает, что данный класс имеет атрибуты, но их показывать в данном конкретном случае не нужно.

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

С помощью диаграммы класса можно отобразить объект, или экземпляр класса. Как и при использовании класса, простейшее представление объекта состоит в изображении прямоугольника, который содержит подчеркнутое имя объекта. Тем самым указывается именованный экземпляр класса. Именованный экземпляр класса можно сопровождать именем класса или обойтись без него.

mySchedule   именованный экземпляр

mySchedule: student_schedule  именованный экземпляр с именем класса

Поскольку реальное имя объекта может быть известно только для программы, которая его объявляет, то в системной документации, возможно, имеет смысл указывать анонимные экземпляры классов. Анонимный объект класса можно представить следующим образом.

:student_schedule

Такой тип обозначения м ожет оказаться удобны м в случае, когда в систе м е существует несколько экзе м пляров класса. Несколько экзе м пляров класса можно представить двумя способами: в виде объектов и в виде классов.

Количество экземпляров, которое может иметь класс, называется множественностью. Количество экземпляров класса (от нуля до бесконечности) можно указать на диаграм м е класса. Класс с нулевым количеством экземпляров является чистым абстрактным классом. Он не может иметь ни одного объекта, явно объявленного с использованием этого типа. Количество экземпляров может иметь нижнюю и верхнюю границы, которые также могут быть указаны на диаграмме класса. На рис. 10.2 показаны возможные варианты обозначения нескольких экземпляров класса на диаграмме класса (с помощью графических средств или значения множественности).

На рис. 10.2 множественность класса student_schedule указана как диапазон 1..7 , а это означает, что наименьшее количество расписаний в нашей системе равно 1, а наибольшее — 7. Приведем еще несколько примеров обозначения множественности класса.

1 Один экземпляр

1..n От одного до заданного числа n.

1.. * От одно г о до бесконечности

0..1 От нуля до единицы

0 * От нуля до бесконечности

* Бесконечное количество экземпляров

Безусловно, бесконечное количество экземпляров будет ограничено объемом внутренней или внешней памяти.

Рис. 10.2. Обозначение нескольких экземпляров класса с помощью графических средств и значения множественности

Отображение информации об атрибутах и операциях класса

Диаграмма класса может содержать более подробную информацию об атрибутах иоперациях класса. В разделе атрибутов можно указать тип данных и/или значение по умолчанию (если оно предусмотрено) для класса и значения атрибутов для объектов. Например, типы данных, содержащиеся в разделе атрибутов класса student_schedule, могут иметь следующий вид.

StudentNumber : string;

Term : string

StudentSchedule : map <string,vector<course> >

ScheduleIterator : map <string,vector<course> >::iterator

Для oбъeктa mySchedule эти атрибуты могут принимать такие значения.

StudentNumber : string = «102933»

Term:string = «Spring»

Методы могут быть отображены с параметрами и с указанием типов возвращаемых ими значений.

studentSchedule(&X : map <string,vector<course> >) : void

StudentNumber () : string

Фу н кция studentSchedule () принимает значение course для заданного студента (course — это класс, который моделирует один курс обучения). Курсы для каждого дня недели хранятся в векторе. Контейнер map устанавливает соответствие строки (дня недели) и вектора курсов (для заданного дня недели). Функция studentSchedule() возвращает void -значение, а функция studentNumber () — значение типа string.

На диаграмме класса можно также отобразить свойства атрибутов и операций (методов). Свойства атрибутов помогают описать характер использования того или иного атрибута, что дает возможность судить о том, можно ли его изменять или нет. Так, для описания атрибутов используются три свойства: changeable, addOnly и frozen. Краткое описание этих свойств приведено в табл. 10.1. Для определения методов используются четыре свойства: isQuery, sequential, guarded и concurrent. Они также описаны в табл.10.1. Свойства sequential, guarded и concurrent имеют отношение к параллельности выполнения методов. Свойство sequential описывает операцию, ответственность за синхронизацию которой лежит на инициаторе ее вызова. Такие операции не гарантируют целостности объекта. Свойство guarded описывает параллельно выполняемую операцию с уже встроенной синхронизацией. При этом guarded -операции означают, что в каждый момент времени возможен только один ее вызов. Свойство concurrent описывает операцию, которая позволяет ее одновременное использование. Операции, описываемые с помощью свойств guarded и concurrent, гарантируют целостность объекта. Гарантия целостности объекта применима к операциям, которые изменяют состояние объекта.

Таблица 10.1. Свойс т ва а т рибу т ов и ме т одов

Свойства атрибутов

{changeable}  На значения этого типа атрибута никакие ограничения не налагаются

{addOnly}  Для атрибутов, y которых значение множественности >1, можно добавлять дополнительные значения. Созданное значение невозможно удалить или изменить

{frozen}  После инициализации объекта значение атрибута изменить нельзя

Свойства методов

{isQuery}  При выполнении метода этого типа состояние объекта остается неизменным. Этот метод возвращает значения

{sequential}  Пользователи этого метода для обеспечения гарантии последовательного доступа к нему должны использовать синхронизацию. При множественном параллельном доступе к этому метолу целостность объекта подвергается опасности

{guarded}  Синхронизированный последовательный доступ к этому методу встроен в объект; целостность объекта гарантируется

{concurrent}  К этому метолу разрешен множественный параллельный доступ: целостность объекта при этом гарантируется

Свойства guarded и concurrent можно использовать для отражения модели PRAM (Parallel Random-Access Machine — параллельнал машина с произвольным доступом). Если метод считывает и/или записывает данные в память, доступную для другого метода, который также считывает и/или записывает данные в гу же память, этот метод может быть описан как PRAM-алгоритм. При этом можно использовать соответствующие свойства, например, такие.

PRAM-алгоритмы

Свойства

CR (Concurrent Read — параллельное чтение)

concurrent

CW (Concurrent Write — параллельная запись)

concurrent

CRCW (Concurrent Read Concurrent Write — параллельное чтение, параллельная запись)

concurrent

EW (Exclusive Write — монопольнал запись)

guarded

ER (Exclusive Read — монопольное чтение)

guarded

EREW (Exclusive Read Exclusive Write — монопольное чтение, монопольная запись)

guarded

Описание класса student_schedule можно сделать еще более подробным, указав с помощью свойств, как использовать его (класса) атрибуты и операции.

Атрибуты:

StudentNumber : string {frozen}

Term : string {changeable}

StudentSchedule : map <string,vector<course> > {changeable}

Операции:

scheduleDayOfWeek(&X : vector<course>, Day : string) :void {guarded}

studentNumber() : string {isQuery, concurrent}

Атрибут StudentNumber представляет собой константу типа string. После присвоения значение константы изменить нельзя. Если объект student_schedule используется для того же студента, но для различных периодов времени, то атрибуты Term и StudentSchedule должны быть модифицируемыми. Метод scheduleDayOfWeek () принимает вектор курсов (vector<course>) для конкретного дня недели, хранимого в строке Day. Это — защищенная (guarded) операция. Она помещает расписание студента, соответствующее конкретному дню недели, в map- объект StudentSchedule, изменяя тем самым его состояние. Синхронизация, встраиваемая в этот объект, обеспечивается за счет использования мьютексов. Метод studentNumber() имеет два свойства: isQuery и concurrent. Этот метод возвращает константу StudentNumber и безопасен для одновременного доступа. Его вызов не изменяет состояния объекта, поэтому здесь и использовано свойство isQuery.

На диаграмме класса можно отобразить е щ е одно важное свойство атрибутов и операций — их видимость. Свойство видимости описывает, кто может получить доступ к атрибуту или вызвать операцию. Для представления этого свойства (уровня видимости) используется соответствующий символ. Уровни видимости соответствуют спецификаторам доступа, определенным в С++.

Симво л видимости предваряет имя атрибута и л и операции (метода).

Спецификаторы доступа

Символы видимости

public

(+) Общий доступ

protected

(#) Доступ имеет сам класс и его потомки

private

(-) Доступ имеет только сам класс

Организация атрибутов и операций

От того, как будут организованы атрибуты и операции в соответствующих отделениях диаграммы класса, зависит степень успешности использования этого класса. Атрибуты и операции можно упорядочить по алфавиту, уровню доступа или категориям. Как оказалось, алфавитный порядок вряд ли поможет узнать, как могут называться те или иные атрибуты или операции (если документация находится в руках пользователя системы), или какие из них еще не определены (если документация используется в процессе разработки). Упорядочение по уровню доступа зарекомендовало себя гораздо лучше. В этом случае пользователь четко видит, какие атрибуты и операции являются, например, общедоступными (public) или закрытыми (private). Знание перечня защищенных (protected) членов поможет расширить возможности класса или специализировать ero, используя механизм наследования. Такое упорядочение просто реализовать с помощью символов видимости (+, - и #) или C++-спецификаторов доступа (public, private и protected,).

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

• конструктор по умолчанию;

• деструктор;

• конструктор копии;

• операции присваивания;

• операции сопоставления на равенство;

• операции ввода-вывода;

• операции хеширования;

• операции запросов.

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

Атрибуты:

• static

• const

Операции:

• virtual

• pure virtual

• friend

При выборе категорий следует исходить из того, какал из них лучше всего описывает услуги, предоставляемые классом. Имя категории справа и слева заключается вдвойные угловые скобки («. . .»). На рис. 10.3 показано два возможных способа организации атрибутов и операций для класса student_schedule, использующих: символы видимости и спецификаторы доступа (рис. 10.3, а) и категории минимально-гостандартного интерфейса (рис. 10.3, б).

Рис. 10.3. Два способа организации атрибутов и операций в диаграмме класса

Шаблонные классы

Шаблонный класс представляет собой механизм, который позволяет в качестве параметра в определении класса использовать тип. Шаблон определяет действия, которые выполняются над переданным ему типом. В С++ параметризованный класс создается с помощью ключевого слова template.

template <class Type > classname { . . . } ;

Параметр Туре представляет любой тип, передаваемый шаблону. Это может быть встроенный С++-тип или определенный пользователем класс. При объявлении параметра Туре шаблон связывается с эле м енто м, переданным ему в качестве параметризованного типа. Например, класс student_schedule включает контейнер map, который содержит векторы объектов типа course для каждого дня недели. Как класс map, так и класс vector являются шаблонными, map <string,vector<course> > StudentSchedule;

Контейнер map использует для ключа тип string, а для значения — тип vector. Контейнер vector содержит объекты определенно г о пользователе м типа course. Контейнер map может отобразить соответствие между значениями двух любых типов данных, а контейнер vector содержать значения любого типа данных.

map <int, vector <string> > Соответствие м ежду число м и векторо м строк

map <int, string> >  Соответствие м ежлучисло м истрокой

vector <student_schedule>  Вектор объектов класса student_schedule

vector <map <int,string> > Вектор отображений, которые устанавливают соответствие между числом и строкой

Шаблонные классы также представляются как прямоугольники. Параметризованный тип представляется как прямоугольник (меньшего размера), начертанный штриховой линией и расположенный в правом верхнем углу прямоугольника класса. Шаблонный класс может быть связанным или несвязанным. При представлении несвязанного шаблонного класса в штриховом прямоугольнике отображается прописнал буква T, означающал несвязанный параметризованный тип. Для представления связанного шаблонного класса существует два способа. Один из них состоит в использовании символа класса, содержащего синтаксис С++ для объявления и связывания шаблонного класса, напри м ер: vector <string>

Этот вариант называется неявным связыванием. В дру г о м способе используется стереотип зависи м ости bind (связать). Этот стереотип задает источник, который реализует шаблонный класс посредство м использования реально г о пара м етризованно г о ти па. Этот вариант называется явным связыванием. Шаблонный объект является реализацией шаблонно г о класса. Он обладает отношение м зависи м ости с шаблонным классом. С помощью стереотипа связать указывается и м я параметра-типа. В штриховом прямоугольнике отображаются соответствующие типы данных. Шаблонный объект можно также рассматривать как детализацию шаблонно г о класса. Детализаци я — это общий термин, означающий более высокий уровень представления информации о том, что уже существует. Стереотипный индикатор «связать» детализирует шаблонный класс посредством реализации параметризованного типа. Способы представления шаблонного класса для контейнера map представлены на рис. 10.4.

Рис. 10.4. Способы представления связанного и несвязанного шаблонного класса

Отношения между классами и объектами

Язык UML определяет три типа отношений между классами:

• зависимости;

• обобщения;

• ассоциации.

Зависимость определяет отношение между дву м я класса м и. Если один класс зависит от другого, это означает, что из м енение, внесенное в независимый класс, может повлиять на зависимый от него класс. Обобщение— это отношение между некоторой общей конструкцией и бо л ее конкретны м типо м этой конструкции. Под об щ ей конструкцией подразумевается родительский класс (или суперкласс), а под более конкретны м ее типо м— сыновний класс (или подкласс). Пото м ок наслелует свойства, атрибуты и операции родителя и м ожет при это м определять собственные атрибуты и операции. Сыновний класс выводится из родительского, и его м ожно использовать в качестве заменителя родительского класса. Класс, не и м ею щ ий родителей (предков), называется корневым, или базовым классом. Ассоциация — это структурное отношение, которое означает, что объекты одного типа связаны с объекта м и другого типа. Ассоциации между объектами двунаправлены. Например, если объект 1 связан с объектом 2, то объект 2 связан с объектом 1 Ассоциация между двумя элементами (например, класса м и) называется бинарной связью, а между nэ л е м ента м и — n-арной.

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

<<bind>> (<<связать>>)

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

Зависимость обозначается пунктирной направленной линией (со стрелкой), которая указывает на зависимую конструкцию. Отношение зависимости следует применять в случае, когда одна конструкция использует другую. Обобщение обозначается сплошной направленной линией со стрелкой, указывающей на родительский класс (суперкласс). Отношение обобщения следует применять в случае, когда одна конструкция выведена из другой. Ассоциация обозначается сплошной линией, которая соединяет одинаковые или различные конструкции. Отношение ассоциации следует применять в случае, когда одна конструкция структурно связана с другой. Некоторые стереотипы и ограничивающие условия, которые применяются к зависимостям, приведены в табл. 10.2. Эти стереотипы используются для отображения зависимостей между классами, интерактивными объектами, состояниями и пакетами. Стереотипы и ограничивающие условия, которые могут применяться к обобщениям и ассоциациям, приведены в табл. 10.3 и 10.4. Если стереотипы используют графические «украшения», они показаны в таблицах.

Таблица 10.2. Стереотипы, применяемые к зависимостям

Зависимость

Описание

<< bind >> (<< связать>>)

источник реализует шаблонный приемник, используя peальные параметры

<<friend>>(<<друг>>)

видимость источника распространяется на содержимое приемника

<<instanceOf>> (<<экземпляр>>)

источник является экземпляром приемника;используется для определения отношений между классами и объектами

<< instantiate>>(<< создать экземпляр>>)

источник создает экземпляры приемника;используется для определения отношений между классами и объектами

<< refine>> (<< уточнить >>)

источник представляет более высокий уровень детализации, чем приемник; используетсядля определения отношений между производным и базовым классами

<< use >>

источник зависит от открытого (public) интерфейса приемника

(<< использовать>>)

<< become>>(<< стать>>)

объект-приемник совпадает с объектом-источником, но в более поздний период жизненного цикла объекта; приемник может иметь другие значения, состояния и пр.

<<call>>

объект-источник вызывает метод приемника

(<< вызвать>>)

<< сору >>(<< копировать>>)

объект-приемник является точной и независимой копией  объекта-источника

<<access >>(<< получить доступ>>)

исходному пакету предоставляется право ссылаться на элементы приемного пакета

<<extend>> (<< расширить>>)

данный прецедент приемника расширяет поведение источника

<<include>>(<< включить>>)

данный прецедент источника может включать прецедент  приемника

Ассоциации имеют еще один уровень детализации, который может быть применен к стереотипам, перечисленным в табл. 10.4:

• Имя Ассоциация может и м еть и м я (название), которое используется для описания природы отношений. К имени может быть добавлен треугольник, указывающий направление, в котором должно читаться имя.

• Роль   Роль обозначает функцию, которую выполняет класс, представленный на одном конце линии ассоциации, относительно класса, представленного на другом конце этой линии.

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

• Передвижение Передвижение по ассоциации может быть однонаправленным, если объект 1 связан с объектом 2, но объект 2 не связан с объектом 1.

Таблица 10.3. Стереотипы и огра н ичивающие условия, которые могут   применяться к обобще н иям

• Стереотип << implementation >> (« реализация ») потомок наслелует реализацию родителя, но не делает открытыми (public) его интерфейсы и не поддерживает их

• Ограничение { complete } ({полнота}) Обусловливает, что все потомки в обобщении получили имена, и никаких дополнительных потомков больше не было выведено

• Ограничение { incomplete }({неполнота}) не все потомки в обобщении получили имена, и дополнительные потомки могут быть выведены

• Ограничение { disjoint } ({несовместимость}) объекты родителя не могут иметь больше одного потомка, используемого в качестве типа

• Ограничение { overlapping }({перекрытие}) объекты родителя могут иметь больше одного потомка,  используемого в качестве типа

Таблица 10.4. Стереотипы и ограничивающие условия, которые могут применяться к ассоциациям

• navigation (передвижение) Описывает однонаправленную (нереверсивную) ассоциацию, при которой объект 1 связан с объектом 2, но объект 2 не связан с объектом 1

• aggregation (агрегирование) Описывает связь «целое-часть», при которой «часть» во время своего существования связана не только с одним «целым»

• composition (композиция) Описывает связь «целое-часть», при которой «часть» во время своего существования может быть связана только с одним «целым»

• Ограничение { implicit } ({неявное}) Обусловливает, что отношение является концептуальным

• Ограничение { ordered } ({упорядоченность}) Обусловливает, что объекты на одном конце ассоциации упорядочены

• Свойство { changeable } ({модифицируемость}) Описывает, что может быть добавлено, удалено и изменено между двумя объектами

• Свойство { addOnly } ({расширяемость}) Описывает новые связи, которые могут быть добав л ены к объекту на противоположном конце ассоциации

• Свойство { frozen } ({жесткость}) Описывает связь, которая после добавления к объекту на противоположном конце ассоциации не может быть изменена или удалена

Интерфейсные классы

Интерфейсный класс используется для модификации интерфейса другого класса или множества классов. Такая модификация упрощает использование класса, делает его более функциональным, безопасным или семантически корректным. Примерами интерфейсных классов могут служить адаптеры контейнеров, которые являются частью стандартной библиотеки шаблонов (Standard Template Librаrу — STL). Адаптеры обеспечивают новый открытый (public) интерфейс для таких контейнеров, как deque (double-ended queue — очередь с двусторонни м доступо м), vector (вектор) и list (список). Расс м отри м при м ер. В листин г е 10.1 представлено определение класса stack, который используется в качестве интерфейсно г о для м одификации класса vector.

// Листинг 10.1. Использование класса stack в качестве

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

template < class Container > class stack {

//...

public:

typedef Container::value_type value_type;

typedef Container::size_type size_type; protected:

Container с;

public:

bool empty(void) const {return c.empty();}

size_type size(void) const {return c.size();}

value_type& top(void) {return c.back(); }

const value_type& top const {return c.back(); }

void push(const value_type& x) {c.push.back(x); }

void pop(void) {c.pop.back(); }

};

Класс stack объявляется путе м задания типа Container

stack < vector< T > > Stack;

В данном случае типом Container является класс vector, но в качестве класса реализации для интерфейсного класса stack (вместо класса vector) можно использо-ватьлюбой контейнер, который определяет следующие методы:

empty () size() back() push.back() pop.back()

Класс stack поддерживает се м антически корректный интерфейс, традиционно принятый для стеков.

Существует несколько способов отображения интерфейса. Один из них — круг, рядом с которым (чаще — под ним) записывается имя интерфейсного класса. Этот способ показан на рис. 10.5, а. Для отображения операций класса stack м ожно также использовать си м волическое обозначение класса (с м. рис. 10.5, б). Здесь над и м ене м класса отображается индикатор стереотипа << interface>>, обозначающий, что это — интерфейсный класс. Имя интерфейсного класса может начинаться с буквы «I», и тогда все операции этого класса булут заметнее отличаться от других классов.

Для отображения отношений м ежду класса м и stack и vector м ожно использовать понятие реализации. Реализация — это се м антическое отношение между классами, в котором один из них предлагает «контракт» (интерфейсный класс), а другой ero выполняет (класс реализации). В наше м при м ере класс stack определ я ет контракт, а класс vector его выполняет. Отношение реализации отображается отрезком пунктирной линии между двумя прямоугольниками классов с крупной полой стрелкой, указывающей на интерфейсный класс, т.е. на класс, который определяет контракт (рис. 10.5, в). Это изображение читается так: «Класс stack реализуется классом vector». Отношение между интерфейсным классом и его реализатором (средством реализации) также можно отобразить в виде «леденца на палочке» (рис. 10.5, г). Класс stack может быть реализован не только классом vector, но и классами list или deque .

Рис. 10.5. Способы представления интерфейсного класса

Организация интерактивных объектов

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

Рис. 10.6. Диаграмма сотрудничества для системы составления расписания

Сотрудничество отображается в виде эллипса (начертанного пунктирной линией), содержащего название вариа н та сотрудничества. Имя сотрудничества должно быть уникальным. Оно представляет собой существительное или короткую фразу, состоящую из существительных, которые входят в словарный состав моделируемой системы. Структурные и поведенческие части сотрудничества отображаются внутри эллипса сотрудничества. Пример структурной части системы составления расписания показан нарис. 10.6. Структурная часть сотрудничества представляет собой сочетание классов и интерфейсов, ко м понентов и узлов. Систе м а, показанная на рис. 10.6, может содержать множество вариантов сотрудничества. Каждый вариант сотрудничества уникален в системе, но его элементы — нет. Элементы одного варианта сотрудничества могут быть использованы в другом варианте за счет иной организации.

Отображение параллельного поведения

При отражении поведенческой характеристики системы акцент ставится на ее динамических аспектах. С этой точки зрения нас интересует, как ведут себя элементы системы при взаимодействии с другими элементами той же системы. Именно во взаимодействии одних элементов с другими и проявляются особенности параллелизма. Диаграммы, используемые в этом разделе, позволяют смоделировать:

• поведение объекта в течение его периода существования;

• поведение объектов, которые совместно работают ради достижения конкретной цели;

• поток управления с акцентом на определенном действии или последовательности действий;

• синхронизацию действий элементов и взаимодействие между ними.

В этом разделе также описаны диаграммы, используемые для моделирования распределенных объектов.

Сотрудничество объектов

Сотрудничество объектов заключается в привлечении друг друга к работе с целью выполнения некоторой конкретной задачи. Они не вступают в постоянные отношения. Одни и те же объекты могут привлекаться разными объектами для выполнения различных задач. Сотрудничество объектов можно представить в виде диаграммы сотрудничества. Диаграммы сотрудничества имеют структурную и интерактивную части. Структурную часть мы рассмотрели выше. Интерактивнал часть отображается в виде графа, вершинами которого являются объекты — участники рассматриваемого сотрудничества. Связи между объектами представляются ребрами. Ребра могут сопровождаться сообщениями, передаваемыми между объектами, вызовами методов и индикаторами стереотипов, которые позволяют подробнее отобразить характер связи.

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

• create  Объект может быть создан

• destroy  Объект может быть разрушен

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

• return  Объекту возвращается значение

• send  Объекту может быть послан сигнал

При вызове и выполнении любо г о м етода воз м ожно наличие передавае м ых параметров и возвра щ аемо г о значения (а также другие действия).

Эти действия могут иметь место, если принимающий объект видим для вызывающего. Для объяснения причины видимости объекта можно использовать следующие стереотипы.

• association Объект видим по причине существования ассоциации (самый общий случай)

• parameter Объект видим, поскольку он является параметром для вызывающего объекта

• local Объект видим, поскольку он имеет локальную область видимости для вызывающего объекта

• global Объект видим, поскольку он имеет глобальную область видимости для вызывающего объекта

• self Объект вызывает собственный метод

Помимо перечисленных, возможно применение и других стереотипов.

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

Рис. 10.7. Диаграмма сотрудничества, использующая порядковые номера для обозначения последовательности выполнения операций

Как показано на рис. 10.7, объект MainObject выполняет две операции в слелующей последовательности:

1: << create >>

2: Value := performAction(ObjectF)

При выполнении операции 1 объект MainObject создает объект Obj ectA. Объект ObjectA локален по отношению к объекту MainObject (поскольку имеет место включение объектов). Это инициирует первую последовательность операций во вложенном потоке управлени я. Дл я обозначения всех операций этой последовательности используется число 1, за которым следует число, отражающее порядок их выполнения. Итак, первая операция последовательности 1 такова: 1.1: initialize()

Объект ObjectA вызывает собственный метод. Выполнение объектом собственно г о метода выражается соединительной линией, связываю щ ей объект с самим собой, и индикатором стереотипа {self} ({caм } ).Onepaция ObjectA::initialize() также запускает другую последовательность действий:

1.1.1 : initializeB()

1.1.2: initializeC()

В этой последовательности два других объекта (которые локальны по отношению кобъекту ObjectA) инициализируются посредством вызова соответствую щ их методов инициализации. Операция 2: performAction(ObjectD)

является началом еще одной вложенной последовательности действий. Объекту ObjectA передается объект ObjectD. Объект ObjectA вызывает операцию, определенную в объекте ObjectD:

2.1: doAction()

Объект ObjectA имеет право вызвать эту операцию, поскольку объект ObjectD является параметро м (переданны м объекто м MainObject), как от м ечено стереотипо м {parameter}. В результате выполнения этой последовательности действий объекту ObjectA возвра щ ается значение и объекту MainObject также возвра щ ается значение. По м и м о ко м бинаций порядковых номеров, обозначение этих вложенных потоков управления можно усилить с помощью линии с зачерненной стрелкой, указывающей в направлении выполнения последовательности действий.

Процессы и потоки

Процесс — это часть работы (кода), создаваемая операционной системой. Он включает один или несколько потоков, выполняемых в его адресном пространстве. Если потоков несколько, то один из них является основным (main thread). Несколько процессов могут выполняться параллельно. Потоки одного процесса могут выполняться параллельно с потока м и дру г их процессов.

При использовании языка UML дл я отображения функционирования процессов и потоков каждый независи м ый поток выполнения считается активным объектом. Активный объект — это объект, который является владельце м процесса или потока. Каждый активный объект может активизировать то, чем он владеет. Активный класс — это класс, объекты которого являются активными. Активные классы можно использовать для моделирования группы процессов или потоков, которые разделяют одни и те же члены данных и методы. Объекты конкретной системы могут не иметь однозначной взаимосвязи с активными объектами. Как упоминалось в главах 3 и 4, при разделении программы на процессы и потоки следует учитывать, что методы объектов могут выполняться в отдельном процессе или отдельных потоках. Следовательно, при моделировании одного такого объекта его можно представить в виде нескольких активных объектов. Отношение между статическими и активными объектами можно изобразить с помощью диаграммы взаимодействия. В систе м е м ожет быть несколько PVM- или MPI-задач, или процессов, и каждую из них м ожно представить непосредственно как активный объект.

Язык UML позволяет представить активный объект или класс таким же способом, как статический объект, за исключением того, что периметр прямоугольника, обозначающего этот объект или класс, обводится более жирной линией. В этом случае можно также использовать следующие два стереотипа:

process

thread

Индикаторы этих стереотипов позволяют отобразить рааличие между двумя типами активных объектов. На рис. 10.8 показана PVM-задача в виде активного класса и активного объекта. Диаграмма сотрудничества может состоять из активных объектов.

Рис. 10.8. Активный объект и класс

Отображение нескольких потоков выполнения и взаимодействия между ними

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

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

• sequential

• guarded

• concurrent

Рис. 10.9. Диаграмма сотрудничества статических и активных объектов в системе составления расписаний

На рис. 10 9 представлена диаграмма сотрудничс ства нескольких активных объектов, которые «совместными усилиями» создают расписание студента. Объект blackboard используется дл я ре г истрации результатов предварительной работы и ее координации, а также представления итогового расписания, сгенерированного решателями задач активных объектов, именуемых в данном случае агентами (agent).

MajorAgent Создает список имеющихся основных курсов

MinorAgent Создает список имеющихся непрофилирующих курсов

FilterAgent Фильтрует список курсов и генерирует список возможных курсов

ScheduleAgent Генерирует несколько вариантов расписаний на основе списка возможных курсов

Объект schedule_of_courses содержит все и м ею щ иеся курсы.

Объекты blackboard и schedule_of_courses доступны при параллельном к ним обращении со стороны нескольких агентов. В данном варианте сотрудничества оба эти объекта видимы для всех агентов. А г енты MajorAgent, MinorAgent, FilterAgent и ScheduleAgent вызывают методы объекта blackboard. Агенты MajorAgent и MinorAgent вызывают методы объекта schedule_of_courses. При этом а г енты Maj orAgent и MinorAgent имеют анало г ичную последовательность обращений к объектам blackboard и schedule_of_courses.

MajorAgentl: currentDegreePlan()

MajorAgent2 : coursesTaken()

MajorAgent3 : scheduleOfCourses ()

MajorAgent4 : suggestionsForMajor ()

MinorAgentl:currentDegreePlan()

MinorAgent2:coursesTaken()

MinorAgent3:scheduleOfCourses()

MinorAgent4:suggestionsForMinor()

Как видите, к имени активного объекта, который вызывает эти методы, присоединяется порядковый номер. Оба объекта параллельно вызывают методы объектов blackboard и schedule_of_courses. Все эти методы параллельно синхронизированы и защищены от одновременного вызова. Методы masterList() и possibleCourses() имеют свойство guarded. Одни объекты могут модифицировать содержимое курсов, а другие— считывать его. Поэтому методы masterList () и possibleCourses () защищены разрешением только последовательного к ним доступа (EREW).

Последовательность передачи сообщений между объектами

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

[list != empty]

getResults()

Функция или метод не выполнится, если заданное условие не будет истинны м. Методы, которые должны быть вызваны несколько раз (напри м ер, при считывании значений из структуры), предваряются признако м итерации (*).

На рис. 10.10 показана диагра мм а последовательностей для объектов систе м ы составления расписания. Чтобы не перегружать эту де м онстрационную диагра мм у, количество объектов в ней ограничено лишь тремя. В диаграммах последовательностей для параллельных объектов или процедур используются символы активизации. Си м вол активизации представляет собой прямоугольник, отображаемый на линии жизни объекта. Наличие символа активизации означает активность объекта или процедуры. Символы активизации используются в случае, когда объект обращается к другому объекту без блокирования. Тем самым становится понятно, что объект или процедура продолжает выполняться или быть активной. На рис. 10.10 показано, что объект blackboard всегда активен. Он порождает объект schedule _agent и нс блокируется. Объект schedule_agent вызывает метод blackboard.masterList() и ожидает получения от него списка курсов. Как упоминалось выше, возвра щ ение метода обозначается стрелкой с «реберным» наконечником. Метод schedule_agent затем вызывает один из собственньвс методов createSchedules (). Для обозначения вызова объектом одного из собственных методов используется специальный символ, состоя щ ий из символа активизации и стрелки вызова. Символ активизации при этом накладывается на уже имеющийся символ активизации. Линия выходит из исходного символа активизации, а ее стрелкауказывает надополнительный символ. После передачи объектом schedule_agent результатов своей работы путем вызова метода blaekboard.possibleSchedule () объект blackboard аннулирует его. Аннулирование обозначается большим символом «X» в конце линии жизни объекта. Стрелка вызова метода, исходящал из объекта blackboard и указываю щ ая на символ «X», означает, что инициатором аннулирования является объект blackboard. Объект blackboard затем порождает объект filter_agent и опять-таки не блокируется. Объект filter_agent вызывает метод blackboard.possibleSchedules () и ожидает получения от него вариантов расписаний. Объект filter_agent после этого вызывает один из собственных методов filterCourses (). После передачи результатов объект filter_agent ликвидирует себя. Объект blackboard последовательно вызывает собственные методы organizeSolution () и updateRecords (), а затем также ликвидируется.

Деятельность объектов

Язык UML можно использовать для моделирования видов деятельности объектов — участников конкретной операции или прецедента. В этом случае строится диаграмма (видов) деятельности, которая представляет собой блок-схему, отражающую последовательные и параллельные действия (или виды деятельности) объектов, принимаю щ их участие в выполнении конкретной задачи. На этой диаграм м е с по м о щ ью стрелок указывается направление передачи управления для соответствую щ их видов деятельности. В то вре м я как в диагра мм ах сотрудничества основное внимание уделяется передаче управления от объекта к объекту, в диагра м мах последовательностей — временному упорядочению потоков выполнения, в диаграммах деятельности акцент ставится на передаче управления от одного действия (или вида деятельности) к другому. В результате действия (или вида деятельности) изменяется состояние объекта или возвра щ ается некоторое значение. Содержи м ое действия (или вида деятельности) называется состоянием действия (или вида деятельности). Состояние объекта представляется в это м случае как конкретный м о м ент в потоке выполнения.

Рис. 10.10. Диаграмма последовательностей некоторых объектов системы составления расписаний

Действие и деятельность и м еют различия. Действия не м огут быть логически подвергнуты декомпозиции или прерваны другими действиями или событиями. Примерами действий могут служить создание или разрушение объекта, вызов метода или функции. Деятельность можно разложить на составные части (другие виды деятельности). В качестве примеров деятельности можно назвать программу, прецедент или процедуpy. Деятельность можно прервать событием, другим видом деятельности или действием.

Диаграмма (видов) деятельности представляет собой граф, узлы которого обозначают действия или виды деятельности, а ребра — безусловные переходы. Безусловность перехода состоит в том, что для того, чтобы он произошел, не требуется никакого события. Переход происходит сразу же по завершении предыдущего действия или вида деятельности. Эта диаграмма содержит ветви решений, символы начала, останова и синхронизации, которые объединяют несколько действий (или видов деятельности) или обеспечивают их разветвление. Состояния действий и видов деятельности представляются аналогичным образом. Для представления состояния действия или деятельности в языке UML используется стандартный символ блок-схемы, который обычно служит для отображения точек входа и выхода. Этот символ применяется независимо от типа действия или деятельности. Мы предпочитаем использовать стандартные символы блоксхемы, которые позволяют отличить действия ввода-вывода (параллелограмм) от действий обработки или преобразования (прямоугольник). Описание действия или вида деятельности, т.е. имя функции, выражения, прецедента или программы, отображается в соответствующем элементе графа. Состояние деятельности может дополнительно включать отображение действий входа и/или выхода. Действие входа— это действие, которое происходит, ко г да и м еет м есто вход в состо я ние деятельности, а действие выхода — это действие, которое происходит непосредственно перед выходо м из состояния деятельности. Эти действия являются первы м и последни м действия м и соответственно, которые должны быть выполнены в состоянии активности.

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

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

Ино г да после завершения одно г о действия или вида деятельности начинается параллельное су щ ествование нескольких потоков, выполняю щ их различные последовательности действий или виды деятельности. В отличие от блок-схемы, язык UML определяет си м вол, который м ожно использовать для представления м о м ента, начинал с которо г о несколько потоков выполняются параллельно. Для отображения этого мо м ента используется си м вол синхронизации, который также служит для обозначения соединения параллельных путей. Этот си м вол и м еет фор м у жирной горизонтальной линии с нескольки м и выходя щ и м и перехода м и (разветвление) или нескольки м и входя щ и м и перехода м и (соединение). Переходы, выходя щ ие из линии синхронизации, означают состояние действия или деятельности, которое приводит к выполнению нескольких потоков. Переходы, входя щ ие в линию синхронизации, означают необходи м ость синхронизации нескольких потоков, а линия синхронизации в это м случае используется для отображения ожидания до тех пор, пока все ветви не соединятся в единую ветвь (поток). При м ер разветвления потоков и их соединения показан на рис. 10.12.

Рис. 10.11. Символ решения, используемый при определении необходимости построения источника знаний (ИЗ)

При создании объекта MajorAgent вызывается его конструктор, который (см. рис. 10.12) инициирует три параллельных потока выполнения. После завершения этих трех действий потоки соединяются в единый поток, назначение которо г о состоит в выполнении действия по созданию списка основных курсов.

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

Назначение этой диаграммы деятельности — смоделировать последовательность действий объекта blackboard, который г енерирует сводный список курсов для систе м ы составления расписаний. Объект blackboard (с м. рис. 10.13) сначала принимает решение о том, нужно ли создавать объект MajorAgent. Если нужно, то вызывается конструктор объекта MajorAgent. Это приводит к созданию трех ветвей передачи управления. В двух из них действия выполняет объект blackboard («получает теку щ ий план выдачи дипломов» и «считывает курсы обучения»), а в третьей — объект ScheduleofCourses («считывает расписание курсов»). Все эти действия — входные (поэтому для их обозначения используются параллело г раммы). Затем три ветви объединяются в одну, и объект MajorAgent выполняет действие, которое состоит в создании списка основных курсов. После то г о как объект blackboard выполнит «свое» действие, а именно «получит список основных курсов», происходит удаление объекта MajorAgent. Объект blackboard «г енерирует сводный список курсов», и на этом деятельность рассматриваемых объектов прекращается.

Конечные автоматы

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

Рис. 10.13 Диаграмма деятельности с «плавательными дорожками», отображающая последовательность действий в системе составления расписаний

Конечный автомат можно представить в виде таблицы или ориентированного графа, именуемого диаграммой состояний. На рис. 10.14 изображена UML-диаграмма состояний для конечного автомата некоторого процесса. На этом рисунке показаны состояния, через которые проходит процесс в период своей активности. Рассматриваемый процесс может иметь в системе четыре состояния: готовности, выполнения, ожидания и останова. К наступлению этих четырех состояний процесса могут привести 8 событий. Три из них происходят только при выполнении определенного условия. Событие блокирования происходит только в том случае, если процесс запрашивает операцию ввода-вывода или ожидает наступления некоторого события. Событие блокирования инициирует переход процесса из состояния выполнения («бодрствования») в состояние ожидания («сна»). «Пробуждение» процесса происходит или из-за события пробуждения или в результате завершения операции ввода-вывода. Событие пробуждения заставляет процесс перейти из состояния ожидания (исходно г о состояния) в состояние г отовности (целевое состояние). Событие выхода происходит только в случае, если процесс выполнит все свои инструкции. Событие выхода заставляет процесс перейти из состояния выполнения в состояние ожидания. Остальные события относятся к категории внешних и не подвластны процессу. Они возникают по некоторым внешним причинам, вынуждающим процесс перейти из некоторого исходного в некоторое целевое состояние.

Рис. 10.14. Диаграмма состояний для процессов

Диаграммы состояний используются для моделирования динамических аспектов объекта, прецедента или системы. Диаграммы последовательностей, видов деятельности, сотрудничества и (добавленнал) диаграмма состояний используются для моделирования поведения системы (или объекта) в период ее (его) активности. Структур-нал часть диаграммы сотрудничества и диаграмма классов позволяют смоделировать структурную организацию объекта или системы. Диаграммы состояний прекрасно подходят для описания поведения объекта вне зависимости от конкретного прецедента. Их следует использовать не для описания поведения нескольких взаимодействующих или сотрудничающих объектов, а для описания поведения объекта, системы или прецедента, который претерпевает ряд преобразований, причем именно в случае, когда одно преобразование может быть вызвано несколькими событиями. Речь идет о таких логических конструкциях, которые весьма активно реагируют на внутренние или внешние события.

10.2. Отображение параллельного поведения 367

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

Состояние имеет несколько частей (они перечислены в табл. 10.5). Состояние можно представить простым отображением его названия в центре соответствующей вершины диаграммы состояний (прямоугольника с закруглёнными углами). Если внутри этого прямоугольника необходимо отобразить также некоторые действия, то для названия состояния должен быть выделен отдельный раздел в верхней части прямоугольника. Действия перечисляются под этим разделом и должны иметь сле-лующий формат отображения:

метка [Условие] / действие или деятельность

Расс м отри м при м ер: do / validate(data)

Здесь do — это метка, которая используется для обозначения выполнения указанного действия до тех пор, пока объект находится в данном состоянии. Имя validate(data) — это имя вызываемой функции, а data — имя аргумента, с которым она вызывается. Если действие состоит в обращении к функции или метолу, то аргументы желательно указывать.

Таблица 10.5. Состав н ые час т и сос т оя н ия

Название Уникальное имя состояния, которое от л ичает е г о от других состо я ний; состояние может не иметь имени

Действия входа-выхода Действия, выполняемые при входе в состояние (состояние входа) или при выходе из него (состояние выхода)

Подсостояния Вложенные состояния; подсостояния — это составные части состояния, которые могут бытьактивизированы последовательно или параллельно. Составное состояние, или суперсостояние, — это состояние, которое содержит подсостояния

Внутренние переходы Переходы, которые совершаются внутри состояния, не вызывал при этом изменения состояния

Самопереходы Переходы, которые совершаются внутри состояния, не вызывая изменения состояния, но приводящие к выполнению входного, а затем выходного действия

Отсроченные события Список событий, которые происходят, пока объект находится вданном состоянии, но помещаются в очередь и обрабатываются, когда объект пребывает уже в другом состоянии

Условие — это условное выражение, которое приводится к значению ЛОЖЬ или ИСТИНА. Если условие дает значение ИСТИНА, выполняется действие или осуществляется деятельность, напри м ер: exit [data valid] / send(data)

Действие выхода (exit) send(data) защищено выражением data valid, которое при вычислении может дать ложное или истинное значение. Если при выходе из данного состояния это выражение даст значение ИСТИНА., то будет вызвана функция send(data). Использование выражения защиты необязательно.

Переходы из одного состояния (объекта, системы или прецедента) в другое происходят при наступлении событий. Существует два вида переходов, которые мотут осуществляться без изменения состояния (объекта, системы или прецедента) — это внутренние и самопереходы.

Самопереход и м еет м есто, когда возникновение конкретного события вынуждает объект выйти из текущего состояния. При выходе из него объект выполняет действие выхода (если таковое прелусмотрено), а затем — действие, связанное с самопереходом (если таковое прелусмотрено). Затем объект снова входит в прежнее состояние, выполняя при этом действие входа (если таковое прелусмотрено). При внутренних переходах объект вовсе не выходит из теку щ е г о состояния и, следовательно, никаких действий (ни входного, ни выходного) не выполняет. На рис. 10.15 показана общая структура состояния, включающая действия входа и выхода, осуществляемую деятельность, а также внутренние и самопереходы. Самопереход обозначается линией, направленной назад к тому же состоянию.

Переход между разными состояниями означает, что между ними существует некоторое отношение. В то время, как объект находится в одном (исходном) состоянии, может произойти некоторое событие или могут создаться определенные условия, которые заставят этот объект перейти в другое (целевое) состояние. Таким образом, переход объекта из состояния в состояние инициируется событием. Один переход может иметь несколько параллельно существующих исходных состояний. В этом случае они соединяются перед осуществлением перехода. Один переход также может иметь несколько параллельно существующих целевых состояний, и тогда имеет место разветвление. Составные части перехода перечислены в табл. 10.6. Переход изобра-кается линией, направленной от исходного состояния к целевому. Имя инициатора события отображается рядом с переходом. Подобно действиям и видам деятельности, события также могут быть защищены. Переход может быть безусловным, а это значит, что для его осуществления не требуется никакого специального события. При выходе из исходного состояния объект немедленно переходит в целевое состояние.

Рис. 10.15. Общая структура состояния

Таблица 10.6. Составные части перехода

Исходное состояние Первоначальное состояние объекта; при осуществлении перехода объект выходит из исходного состояния

Целевое состояние Состояние, в которое объект входит после осуществления перехода

Событийный инициатор Событие, которое инициирует осуществление перехода. Переход может быть безусловным (т.е. не иметь инициатора), в эгом случае переход происходит сразу же после того, как объект завершит все свои действия (видыдеятельности) в исходном состоянии

Защитное условие Булево выражение, связанное с событийным инициатором, которое обеспечивает осуществление перехода только в случае, если при вычислении дает значение ИСТИНА

Действие Действие, выполняемое объектом при осуществлении перехода; оно может быть связано с событийным инициатором и/или защитным условием

Параллельные подсостояния

Подсостояние позволяет еще больше упростить описание модели поведения системы с параллелизмом . Подсостояние— это состояние, которое является составной частью другого состояния, именуемого суперсостоянием или составным состоянием. Такое представление означает, что состояние можно разбить на несколько подсостояний. Эти подсостояния могут существовать последовательно или параллельно. Параллелизм подсостояний означает, что один объект может быть занят в двух независимых поведенческих множествах. Это справедливо для нашего объекта «классной доски» (blackboard). При обработке каждого возможного расписания он должен обновлять соответствующие структуры и выполнять другие обслуживающие процедуры. Каждое подсостояние отображается в отдельном разделе. Подсостояния синхронизируются и объединяются перед выходо м из составного состояния. Когда одно подсостояние подходит к концу, оно ожидает, пока другие состояния подойдут к концу, после чего подсостояния снова соединяются в одно. На рис. 10.16 показана диаграмма состояний для объекта blackboard, который генерирует расписание для студентов.

Состояние Генерирование расписания (с м. рис. 10.16) яв л яется составны м. Его параллельные подсостояния называются Фильтрование и Обновление. Подсостояния отделяются пунктирной линией и представляются собственными конечными автоматами, причем каждый конечный автомат имеет свои начальное и конечное состояния. В подсостояний Фильтрование объект последовательно проходит через следующие состояния: Фильтрование временных конфликтов, Балансировка и Персонификация. В под-состоянии Поддержка объект проходит только через одно состояние: Обновление. Ко г да оба подсостояния Фильтрование и Поддержка (вернее, соответствую щ ие им конечные автоматы) достигают своих конечных состояний, то перед выходом из составного состояния Генерирование расписания происходит их объединение.

Рис. 10.16. Диаграмма состояний для объекта blackboard

Распределенные объекты

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

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

Существует два способа смоделировать местоположение компонентов или объектов в UML-диаграмме развертывания: посредством вложения или использования тегированного значения.

Согласно первому способу компоненты, которые располагаются в узле, перечисляются внутри символьного обозначения узла. Второй способ предлагает отображать местоположение компонентов в символе компонента. Узлы являются частью диаграммы развертывания. В качестве символа узла используется куб. Куб может иметь два отдельных раздела: один будет содержать индикатор стереотипа, описывающий тип узла, а второй — список компонентов, относящихся к этому узлу (первый способ). При использовании символа компонента (второй способ) тегу location (местоположение) присваивается имя уала, в котором размещается данный компонент. Тег location имеет следующий формат: {location = имя узла}

Тег location может быть частью любой диаграммы, в которой местоположение компонентов является существенным фактором (например, в диаграммах сотрудничества, объектов или видов деятельности). На рис. 10.17 отображены два способа обозначения местоположения компонентов в распределенной системе. В части а этого рисунка показан символ узла, содержащий список компонентов, а в части б представлен символ активного объекта, в котором используется тег location.

Визуализация всей системы

Рис. 10.17. Способы отображения местоположения компонента в распределенной системе

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

Рассмотренные в этой главе диаграммные методы позволяют разработчику взглянуть на систему с различных точек зрения, с различных уровней, как извне, так и изнутри. В этом разделе мы обсудим моделирование системы в целом. Это означает, что на самом высоком уровне моделирования следует отображать только основные компоненты или функциональные элементы. Диаграммные методы, предлагаемые для рассмотрения в этом разделе, используются для моделирования развертывания системы и ее архитектуры. И хотя этот раздел — последний в этой главе, моделирование и документирование системы в целом должно быть первым этапом ее проектирования и разработки.

Визуализация развертывания систем

Развертывание системы — последний этап в ее разработке. При развертывании системы имеет смысл смоделировать реальные физические компоненты исполняемой версии системы. Диаграмма развертывания отображает конфигурацию элементов оборудования и программных компонентов. Программные компоненты представляют собой такие реальные выполняемые модули, как активные объекты (процессы), библиотеки, базы данных и пр. Диаграмма развертывания состоит из узлов и компонентов. Компоненты - это экземпляры физической реализации логических элементов. Например, класс— это логический элемент, который может быть реализован в виде одного или нескольких компонентов. Класс можно разделить на процессы или потоки, и каждый процесс или поток в диаграмме развертывания может быть компонентом. Компоненты класса могут выполняться на различных узлах одного компьютера (потоки/процессы) или различных компьютерах (процессы).

Узел обозначается в виде куба. Узлы соединяются связями. Компоненты и узлы также могут соединяться связями. Как упоминалось выше, узел может содержать список компонентов, либо компонент может быть отображен отдельно от узла, но при этом необходимо показать связь между ними. Компонент можно представить в виде прямоугольника с указанием тегов в его левой части. Имя компонента указывается внутри его символьного обозначения.

Для отображения более крупных частей системы компоненты можно сгруппировать в пакеты или подсистемы. Пример диаграммы развертывания показан на рис. 10.18. Здесь пользователи подключаются к системе через intranet. Узлы являются частью кластера компьютеров. Они группируются в пакет. Пользователи подключаются к кластеру как к единому элементу. В каждом узле перечисляются программные компоненты, которые на немустановлены. Взаимодействие межлуузлами обеспечивается посредством сетевого узла.

Рис. 10.18. Диаграмма развертывания, использующая пакеты

Архитектура системы

Моделирование и документирование архитектуры системы — это ее описание па самом высоком уровне. Гради Буч, Джеймс Рамбау и Айвар Джекобсон определяю, архитектуру как

набор важных решений по организации системы программного обеспечения, выбор структурных элементов и их интерфейсов, посредством которых составляется система, вместе с их поведением, определенным на периоды их сотрудничества, объединение этих структурных и поведенческих элементов в более крупные подсистемы и архитектурный стиль, который направляет эту организацию — эти элементы и их интерфейсы, их варианты взаимодействия и их композицию.

Моделирование и документирование архитектуры системы должно охватывать ее логические и физические элементы, а также структуру и поведение системы на самом высоком уровне.

Архитектура системы — это ее описание с различных точек зрения, но с акцентом на структуре и организации системы. Ниже представлены различные точки зрения.

Прецедент (вариант использования)  Описывает поведение системы с точки зрения конечно г о пользователя

Процесс  Описывает процессы и потоки, используемые в механизмах обеспечения параллелизма и синхронизации

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

Реализация  Описывает аппаратные компоненты, используемые для создания физической системы

Развертывание  Описывает про г раммные компоненты и узлы, на которых они выполняются, в поставляемой системе

Очевидно, что эти «поля зрения» (представления о системе) частично перекрываются и взаимодействуют между собой. Например, в описании назначения системы могут упоминаться прецеденты, а при описании ее реализации процессы часто представляют в качестве компонентов. Программные компоненты используются как в части реализации, так и части развертывания системы. При описании архитектуры системы очень полезно строить диаграммы, которые отражают каждый из перечисленных выше ее «портретов».

Систему можно разложить иа подсистемы и модули. Подсистемы и модули могут быть подвергнуты дальнейшей декомпозиции и разложены на компоненты, узлы, классы, объекты и интерфейсы. В языке UML подсистемы и модули, используемые на архитектурном уровне документации, называются пакетами. Пакет можно использовать для организации элементов в группу, которая описывает общую цель этих элементов. Пакет представляется в виде прямоугольника со вкладкой (ярлыком), расположенной над его верхним левым углом. Символ пакета должен содержать его название. Пакеты в системе могут связывать отношения, построенные на основе композиции, агрегирования, зависимости и наследования. Для того чтобы отличать один тип пакета от другого, можно использовать индикаторы стереотипов. На рис. 10.19 показаны пакеты, входящие в систему составления расписаний. Для системного пакета используется индикатор <<system>> (<<система>>), а для пакета уровня подсистемы — индикатор «subsystem>> (<<подсистема>>). Подсистемы связаны с системой отношением агрегирования.

Одни пакеты могут содержать другие пакеты. В этом случае имя пакета указывается во вкладке. На рис. 10.19 также показано содержимое каждой подсистемы.

Резюме

Рис. 10.19. Пакеты, используемые в системе составления расписаний (NLI- естественно-языковый интерфейс; NLP — обработка данных на естественном языке; NLG — генерация словаря естественного языка)

Модель системы представляет собой своего рода информационное тело, «собранное» с целью изучения системы. При моделировании любой системы не обойтись без документирования ее различных аспектов. Поскольку в создании системы обычно занято множество людей, очень важно, чтобы все они пользовались одним языком. Таким языко м стал у н ифицированный язык м оделирования (United Modeling Language — UML), который представляет собой совокупность графических средств, используемых для проектирования, визуализации, моделирования и документирования артефактов системы программного обеспечения. Этот язык создан Гради Бучем, Джеймсом Рамбау и Айваром Джекобсоном. Язык UML стал фактическим стандартом для моделирования объектно-ориентированных систем. Его средства также успешно можно использовать для моделирования параллельных и распределенных систем в плане описания ее структурных и поведенческих аспектов.

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

Диаграммы развертывания используются для моделирования системы с точки зрени я их поставки. Базовыми элементами диаграммы развертывания являются узлы и компоненты. Узлы представляют блоки оборудования, а компоненты— части программного обеспечения. В символах узлов указывается, какие объекты или компоненты установлены на них. При моделировании всей системы базовым элементом является пакет. Пакеты можно использовать для представления систем и подсистем. Межлу пакетами могут существовать отношения, которые также отражаются на диаграмме.

Проектирование компонентов для поддержки параллелизма

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

Рей Курзвейл (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-потоков данных

Итак, рассмотрим определение операторов "«" и ">>" для класса 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-потоков данных

Чтобы понять, как определенный пользователем класс можно использовать совместно с классом 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

Объектно-ориентированные каналы и FIFO-очереди как базовые элементы низкого уровня

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

• буфер;

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

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

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

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

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

• порт ввода;

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

• буфер;

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

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

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

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

Эти компоненты образуют минимальный набор характеристик, составляющих описание канала. Уточнив базовые компоненты, можно поразмыслить о том, как при разработке объектно-ориентированного канала лучше всего использовать существующие системные 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) ;

Связь каналов c iostream-объектами с помощью дескрипторов файлов

Существует три 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 ().

Доступ к анонимным каналам c использованием итератора ostream_iterator

Канал можно также испо л ьзовать с итераторами 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. Но использование основных механизмов тех же методов объектно-ориентированного программирования все же позволяет понизить уровень сложности параллельного и распределенного программирования.

FIFO-очереди (именованные каналы),

Методы, которые мы использовали для реализации объектно-ориентированных анонимных каналов, обладают двумя недостатками. Во-первых, любым процессам, которые взаимодействуют с другими процессами, нужен доступ к файловым дескрипторам, возвращаемым при вызове системной функции 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, которая восполняет собой отсутствие реальной синхронизации.

Интерфейсные FIFO-классы

Упростить межпроцессное взаимодействие (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 мы подробнее остановимся на каркасных классах, которые поддерживают параллелизм. Мы также рассмотрим использование стандартных С++-алгоритмов, контейнеров и объектов функций для управления процессом создания множества задач или потоков в приложениях, требующих параллелизма.

Реализация агентно-ориентированных архитектур

Нам предстоит сделать еще немало, прежде чем мы поймем, как люди описывают свои задачи и какую роль эти описания играют в решении задач. Но мы уже знаем достаточно для того, чтобы предположить, что используемые людьми описания, представленные как в виде высказываний, так и в форме рисунков, могут быть сымитированы компьютерами.

ГербертА. Саймон(Неrbеrt. Simon), Machine as Mind (Android Epistemology)

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

Что такое агенты

Когда объектное программирование впервые залвило о себе, сама трактовка понятия объекта вызвала большие споры. Подобные разногласия вызывает и трактовка понятия агента. Одни определяют агенты как автономные постоянно выполняющиеся про-траммы, которые действуют от имени пользователя. Однако это определение можно применить и к UNIX-демонам или даже некоторым драйверам устройств. Другие дополняют это определение тем, что агент должен обладать специальными знаниями пользователя, должен выполняться в среде, «населенной» другими агентами, и обязан действовать только в рамках заданной среды. Эти требования должны исключать другие программы, которые можно было бы до некоторой степени считать агентами. Например, многие агенты электронной почты действуют автономно и могут работать по многих средах. Кроме того, в различных кругах программистов для описания агентов появились такие термины, как софтбот, т.е. программный робот (softbot), база знаний (knowbot), программный брокер (software broker) и интеллектуальный объект (smart object). В этой главе мы многократно будем определять термин агент. Начнем с простых согласованных частичных определений и построим определение, которое бы устраивало С++-программистов.

Существует определение, согласно которому агент определяется как некоторая сущность, функционирующая постоянно и автономно в среде, в которой выполняются другие агенты и процессы. Хотя весьма заманчиво принять это определение и развить его, мы не будем этого делать, поскольку оно «с таким же успехом» описывает и другие виды программных конструкций. Многие объектно-ориентированные компоненты функционируют постоянно и автономно в среде, в которой выполняются другие процессы и существуют другие агенты. И в самом деле, многие CORBA-ориентированные системы типа «клиент-сервер» вполне соответствуют этому описанию! Поэтому, если мы заменим в этом определении слово агент словом объект, оно в точности опишет многие объектно-ориентированные системы. Если заглянуть в более официальный источник, Foundation for Intelligent Physical Agents (FIPA), то в соответствии с ним термин агент определяется следующим образом:

Агент — это главный исполнитель в домене. Он обладает одной или несколькими сервисными возможностями, образующими единую и комплексную модель выполнения, которая может включать доступ к внешнему ПО, пользователям (людям) и средствам связи.

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

Агенты: исходное определение

Одной из причин, по которой слово объект может заменить с л ово агент во многих определениях и описаниях агента, состоит в том, что агенты по сути основаны на объектах. И в самом деле, наше первое требование к определению агента заключается в том, что оно в первую очередь должно удовлетворять определению объекта [19], т.е. мы имеем в виду, что агент — это объект определенного вида. В этой главе особый акцент делается на том, что отличает агента от других категорий объектов. Исходя из того, что С++ поддерживает интерфейсные, контейнерные и каркасные классы, мы можем с таким же успехом ввести и агентные классы. Это приводит нас ко второму требованию, выдвигаемому к определению агентов в С++-среде. В С++ агент реализуется с использованием понятия класса. Типы классов отличаются друг от друга тем, как они функционируют, или тем, как они структурированы. Например, контейнерный класс описывает объект, используемый для хранения других объектов. Интерфейсный класс применяется для описания объекта, который преобразует или адаптирует интерфейс другого объекта. Каркасный класс описывает объект, который содержит шаблон, или образец поведения, являющегося общим для целого семейства других объектов. Агентные классы предназначены для определения объектов, которые обладают тем, что Иогав Шохам (Yohav Shoham) описывает как психическое (интеллектуальное) состояние: «Психическое состояние должно включать такие компоненты, как представления, возможности, варианты выбора и обязательства». Это психическое состояние зачастую описывается моделью убеждений, желаний и намерений (Belief, Desires and Intentions — BDI). Мы расширяем модель BDI, чтобы включить в нее действия. Теперь в нашем первом определении агент описывается как часть ПО, отвечающая следующим требованиям.

1. Это определенный тип объекта (т.е. не все объекты являются агентами).

2. Его реализация использует понятие класса (для агентов весьма существенны инкапсуляция, наследование и полиморфизм).

3. Он содержит набор поведенческих вариантов и атрибутов, которые должны включатьубеждения, желания, намерения идействия.

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

Типы агентов

Существует несколько категорий агентов. Несмотря на то что не все агенты можно отнести к одной из них, с их помощью все же можно описать большинство агентов, которые уже нашли практическое применение. В табл. 12.1 перечислено пять основных категорий агентов. Очевидно, существуют и агенты смешанного типа, которые можно отнести к нескольким категориям одновременно, поскольку для распределения агентов по категориям нет никаких жестких правил. Эти категории представлены для удобства и используются в качестве отправной точки в попытке классифицировать агенты, которые, возможно, вам придется разрабатывать или использовать в своей работе.

В табл. 12.1 не указаны компоненты, которые должны иметь агенты. Здесь определены лишь виды деятельности, которые характерны для агентов той или иной категории. При этом следует понимать, что эти категории не являются исключительной сферой агентов. Подобным образом по категориям можно разделить и другие классы ПО (например, экспертные и объектно-ориентированные системы). В нескольких случалх единственным отличием может оказаться сам факт того, что мы говорим об агентах, а не об объектах или экспертных системах.

Табл и ца 12.1. Пять ос н ов н ых категор и й аге н тов

Интерфейсные агенты Представляют следующее поколение взаимодействия между человеком и компьютером. Эти агенты обеспечивают новый пользовательский интерфейс с компьютером

Агенты поиска Выполняют различные виды поиска информации

Агенты мониторинга /управления Патрулируют, наблюдают, отслеживают (выполняемые действия), управляют и контролируют устройства и условия, данные и процессы

Агенты сбора данных Уполномочены запросить некоторые данные или услуги от имени пользователя

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

В чем состоит разница между объектами и агентами

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

•  м етода м и, которые реализуют некоторую фор м у дедукции, индукции или абдукции;

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

Слелует иметь в виду, что в объектно-ориентированном программировании подпрограммы, определенные для класса, называются методами, а в С++— функциями-членами. Пере м енные или ко м поненты данных, определенные для класса, называются атрибутами, а в С++ — членами данных. Если некоторые функции-члены используются для реализации дедукции, индукции или абдукции с использование м членов данных, которые представляют собой реализации когнитивных структур данных, то такой объект является рациональным. Если рациональный объект при этом пересекает определенный порог автономности, то это и есть агент.

Когнитивные структуры данных — это структуры, используемые для представления таких интеллектуальных компонентов, как убеждения, намерения, обязательства, решения, настроения и знания. Например, мы могли бы обозначить структуру убеждений, используя С++-множество (set).

set<statements> Beliefs;

struct statement{

//. . .

float ArrivalTime;

float DepartureTime;

string Destination;

//.. .

};

Здесь инструкции связаны с составлением расписания для некоторого вида общественного, транспорта. Коллекция этих инструкций хранится в С++-множестве set<statements> и представляет «убеждения» агента. Это именно то, что мы подразу м евае м под члена м и данных, которые являются реализация м и когнитивных структур данных. Агент должен объявить член данных соответствующим образом.

class agent{

//.. .

set<statements> Beliefs;

//. . .

};

В классе agent для обработки множества Beliefs, чтобы сфор м ировать на м ерения, обязательства или планы, используется дедукция, индукция или абдукция. Из нашего определения агентов следует, что, если мы имеем дело с рациональным автономным объектом, то мы имеем дело с агентом. Если он не рациональный, то он не агент, он — просто объект. А о степени автономности мы поговорим подробнее ниже в этой главе.

Понятие об агентно-ориентированном программировании

Агентно-ориентированное программирование — это процесс назначения работы, порученной программе, одному или нескольким агентам. В декомпозиции работ (Work Breakdown Structure — WBS) в этом случае участвуют только агенты. Если всю работу, которую должна выполнить программа, можно назначить одному или нескольким агентам, мы имеем дело с чистой агентно-ориентированной программой, в которой весь необходимый объем проектирования и разработки требует только агентно-ориентированного программирования. Во многих ситуациях нарялу с агентами в приложении будут задействованы и другие виды объектов и систем, которые не являются агентно-ориентированными, и, следовательно, такое программирование нельзя назвать агентно-ориентированным. Подобное сотрудничество часто имеет место, когда агенты участвуют в работе серверов баз данных, серверов приложений и других типов объектно-ориентированных систем. При создании систем ПО — либо полностью агентно-ориентированных, либо только частично — создаются рациональные объектно-ориентированные программные компоненты.

§ 12:1 Дедукция, индукция и абдукция

Дедукция, индукция и абдукция — это процессы, используе м ые для того, чтобы сделать вывод на основании набора утверждений или коллекции данных. Процесс дедукции позволяет механизму рассуждений прийти к заключению, оценив множество утверждений. Если эти утверждения (посылки) истинны, и механизм рассуждений следует соответствующим правилам генерирования вывода, то это дает основания утверждать, что непременно истинны и следствия, например:

Все фигуры с тре м я сторона м и являются треугольника м и.

Даннал фигура и м еет три стороны.

Эта фигура — треугольник. <— Вывод получен по делукции.

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

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

Вчера шел дождь.

Позавчера шел дождь.

Дождь шел всю прошлую неделю.

Завтра будет идти дождь. <— Вывод получен по индукции.

Тогда как следствия, полученные в процессе дедукции объявляются непременно истинными (если правила генерирования вывода были применены корректно), то заключения, к которым приходят в процессе индукции, имеют лишь некоторую вероятность быть истинными. Насколько близко эта вероятность приближается к 100%, зависит от характера и контекста утверждений, а также данных, на которые они опираются.

Процесс абдукции позволяет механизму рассуждений сделать наиболее правдоподобный вывод на основе набора утверждений или данных, например, так. Предметы одежды обвиняемого были обнаружены на месте преступления. Межлу обвиняемым и покойником недавно произошел бурный конфликт. ДНК обвиняемого была обнаружена на месте преступления.

Обвиняемый виновен в свершении преступления. <— Вывод получен по абдукции.

Делукция, индукция и абдукция — это три основных процесса логического мышления. Их роль в логике можно сравнить с ролью вычислений и арифметики в математике. Способность корректно переходить от посылок (утверждений, данных и фактов) кзаключениям является процессом, который мы называем рассуждением.

Основные правила генерирования вывода

Роль агентов в распределенном программировании

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

Оба эти вида архитектуры м огут использовать преи м у щ ества агентов, поскольку агенты представ л яют собой са м одостаточные, автоно м ные и рациональные программные структуры. Рациональность агентов зак л ючается в том, что им известно их назначение. И обычные объекты имеют це л ь, но агенты «знают», какова эта цель. Идентификация наз н аче н ия каждого аспекта ПО — вполне естественный процесс. На этане проектирования нетрудно продумать цель отдельной части ПО, и поэтому простейшая форма декомпозиции ПО состоит в том, чтобы назначить агенту его цель. Затем приходит черед понять, агентов какого класса лучше всего уполномочивать на выполнение той или иной работы. Поскольку агент— это единица модульности в агентно-ориентированной программе (agent-oriented program — АОР), то проблема распределения сводится к поиску средств взаимодействия множества агентов. Процесс проектирования исходного класса агента вбирает в себя все то, что необходимо для идентификации отдельных составных частей распределенной программы. Справившись с созданием агентов как действительно рациональных объектов, мы сможем воспользоваться преимуществами CORBA-спецификации для разработки действительно распределенных мультиагентных систем. CORBA скрадывает сложность распределенного программирования и взаимодействия посредством сетей (intranet Hlnternet). Обзор средств распределенного программирования с использованием CORBA-сиецификации приведен в главе 8. Поскольку агенты являются объектами, этот обзор CORBA-средств имеет силу и для агентов. В главе 6 рассмотрена система PVM (Parallel Virtual Machine — параллельнал виртуальная машина). Систему PVM также можно использовать для значительного упрощения взаимодействия между агентами, существующими в различных процессах или на разных компьютерах. Агенты можно реализовать как CORBA-объекты, либо их можно назначить отдельным PVM-процессам. В обоих случалх взаимодействие агентов упрощается в значительной степени. Если в одном приложении задействовано несколько агентов, то такое приложение представляет собой мультиагентную систему. Если агенты расположены на одном компьютере, то для взаимодействия между собой они могут использовать CORBA-, PVM- или MPI-средства (Message Passing Interface). Агенты в различных процессах также могут использовать такие традиционные методы межпроцессного взаимодействия (IPC), как FIFO-структуры, разделяемую память и каналы. В распределенном программировании есть три основные проблемы.

1. Идентификация декомпозиции ПО распределенного решения.

2. Реализация эффективного и рационального взаимодействия между распределенными компонентами.

3. Обработка исключительных ситуаций, ошибок и частичных отказов.

Несмотря на то что для реализации п. 2 в понятии класса агента нет ничего такого, что было бы свойственно только агентам, смысл п. 1 и 3 почти подразумевается в самой сути агента. Рациональность каждого агента определяет его назначение, а следовательно, и роль, которую он будет играть в решении ПО. Поскольку агенты самодостаточны и автономны, то хорошо продуманный класс агента должен включать необходимые меры по обеспечению их отказоустойчивости.

Агенты и параллельное программирование

При размещении агентов в среде с несколькими процессорами или параллельно выполняющимися потоками вы получаете такие же преимущества, как и при распределенном программировании, но с той лишь разницей, что сотрудничество между агентами программировать в этом случае гораздо проще. Для передачи сообщений между агентами, которые коллективно решают задачи некоторого вида, также можно использовать PVM- и MPI-среды. И снова-таки, рациональность агентов облегчает понимание, как следует провести декомпозицию работ для параллелизма. В параллельном программировании, как правило, встречаются такие проблемы.

1. Эффективное и рациональное разделение работы между несколькими компонентами.

2. Координация параллельно выполняющихся программных компонентов.

3. Разработка соответствующего взаимодействия (когда это необходимо) между компонентами.

4. Обработка исключительных ситуаций, ошибок и частичных отказов (если агенты функционируют на отдельных компьютерах).

Мультиагентные параллельные архитектуры часто характеризуются как слабосвязанные, т.е. им присущ минимум взаимодействия и взаимозависимости. Каждый агент знает свою цель и обладает методами для ее достижения. В то время как п. 3 не подвластен классу агента, п. 1, 2 и 4 можно легко управлять с помощью классов агентов. Например, при использовании агентов влияние п. 2 уменьшается, поскольку каждый агент рационален, имеет цель, а также способы и средства ее достижения. Поэтому вся ответственность смещается с алгоритма координации и управления на действия каждого агента. Влияние п. 4 также уменьшается, поскольку агенты самодостаточны, рациональны и автономны, а кроме того, хорошо продуманный класс агента должен включать необходимые меры по обеспечению отказоустойчивости агентов. Поскольку состояние агента инкапсулировано, ответственность за защиту критических разделов в объекте агента целиком воалагается на класс агента. Агент должен приводить в исполнение собственные стратегии доступа к данным. Возможные стратегии доступа, из которых могут выбирать агенты, перечислены в табл. 12.2.

Таблица 12.2. Стратегии доступа

EREW  Монопольное чтение, монопольная запись

(Exclusive Read Exclusive Write)

CREW  Параллельное чтение, монопольная запись

(Concurrent Read Exclusive Write)

ERCW  Монопольное чтение, параллельная запись

(Exclusive Read Concurrent Write)

CRCW  Параллельное чтение, параллельная запись

(Concurrent Read Concurrent Write)

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

Базовые компоненты агентов

Агент объявляется с использованием ключевого слова class. Компоненты агента должны состоять из С++-членов данных и функций-членов. Логическая структура класса агента показана на рис. 12.1.

Класс агента (см. рис. 12.1) определяет типичные методы инициализации, чтения и записи, которые должен иметь практически любой объект. В «джентльменский набор» входят конструкторы, деструкторы, операторы присваивания, обработчики исключений и т.д. Атрибуты этого класса включают переменные состояния, определяющие объект. Если же ограничиться перечнем этих атрибутов и методов, мы получим только традиционный объект. Рациональный компонент создают когнитивные структуры данных и методы рассуждений (логического вывода). А ведь именно рациональный компонент трансформирует «обычный» объект в агент.

Рис. 12.1. Логическая структура класса агента

Когнитивные структуры данных

Под структурой данных пони м ается набор правил, при м еняе м ых д ля логической организации данных, а также правила доступа к этой логической организации. Именно метод организации определяет, как данные должны быть концептуально структурированы и какие операции доступа могут быть применены к этой структуре. Если для типов данных вообще и абстрактных типов данных (abstract datatypes — ADT) в частности важно, что хранить, то для структур данных важно, как хранить. Напри м ер, целочисленный тип данных определяет некоторую «сущность», которая характеризуется наличием компонента данных и некоторого количества арифметических операций (например, сложение, вычитание, умножение, деление и т.д.). Этот компонент данных не имеет дробной части и состоит из отрицательных и положительных чисел. Спецификация типа данных ничего не «говорит» о том, как целые числа нужно использовать или как к ним получить доступ. Однако спецификация структуры данных (например, стека) определяет список элементов, сохраняемых по принципу «последним прибыл — первым обслужен» (last-in-first-out— LIFO). Структура данных стека также определяет, что элементы из нее можно извлекать только по одному за раз и причем только из вершины стека. Другими словами, элемент, помещенный в стек последним, должен быть извлечен из него раньше остальных элементов. Это означает, что структура данных стека определяет не только характер организации элементов, но и характер доступа к ним (т.е. как элементы можно помещать в структуру, опрашивать, изменять, удалять и т.п.). Когнитивные структуры данных ограничивают правила организации данных и доступа к ним такими, которые относятся к области логики и эпистемологии. Особенности когнитивных структур данных определяются правилами логического вывода, методами рассуждений (т.е. делукцией, индукцией иабдукцией), понятиями эпистемологических данных, знания, обоснования, убеждений, посылок, высказываний, ошибочных доказательств и заключений. [21]

Тогда как для традиционных структур данных вполне обычными являются, например, алгоритмы сортировки и поиска, то для когнитивных структур данных более приемлемы методы рассуждений. Абстрактные типы данных, используемые вместе с когнитивными структурами данных, часто включают следующие:

вопросы  события

факты  вре м я

предположения  заблуждения

убеждения  цель

утверждени я   обоснование

заключения

Безусловно, с когнитивными структурами данных можно сочетать и другие типы данных, но приведенные выше являются характеристиками программ, которые используют такие рациональные программные компоненты, как агенты. Эти абстрактные типы обычно реализуются как типы данных, объявленные с помощью ключевых слов struct или class. Напри м ер, так.

struct question{

class justification{

//...

//...

string RequiredInformation;

time EventTime;

target_object QuestionDomain;

bool Observed;

string Tense;

bool Present;

string Mood;

//...

//... };

};

Шаблонные и контейнерные С++-классы можно использовать для организации таких когнитивных структур данных, как знания, например, так.

class preliminary_knowledge{ //.. .

map<question,belief> Opinion;

map<conclusion, justification> SimpleKnowledge;

set<propositions> Argument; //.- .

};

Методы рассуждений

Под методами рассуждений (см. рис. 12.1) пони м ают дедукцию, индукцию и абдукцию. (Краткое описание этих методов приведено в параграфе 12.1.) Несмотря на то что в агентно-ориентированной архитектуре требуется их использование, не существует конкретных ссылок на то, как они реализуются. Делукция, индукция и абдукция относятся к процессам высокого уровня. Подробности реализации этих процессов — личное дело разработчика ПО. Рассуждение — это процесс выведения логического заключения на основании посылок, истинность которых предполагается или точно установлена. Не существует единственно правильного способа реализации процесса рассуждений, ино г да называе м о г о машиной (и л и м еха н из м о м) логического вывода. При этом на практике приме н яется н еско л ько распростра н е н ных способов реализации это г о процесса. Напри м ер, можно испо л ьзовать методы прямого построения цепочки (рассуждений от исходных посылок к целевой гипотезе) или обратного построения цепочки (рассуждений от целевой гипотезы к исходным посылкам). Нашли здесь применение методы анализа целей и средств, а также такие алгоритмы обхода графов, как «поиск вглубь» (Depth First Search — DFS) и «поиск в ширину» (Breadth First Search — BFS). Существует также целал совокупность методов доказательства теорем, которые можно использовать для реализации методов рассуждений и механизмов логического вывода. Здесь важно отметить, что класс агента может иметь один или несколько методов рассуждений. Описание самых основных способов их реализации приведено в табл. 12.3.

Таблица 12.3. Основные способы реализации методов рассуждений

Обратное построение цепочки Управляемый целями метод, в котором процесс начинается с предположения, утверждения или гипотезы и стремится найти подтверждающие доказательства

Прямое построение цепочки Управляемый данными метод, который начинается с анализа имею щ ихся данных или фактов и приходит к определенным выводам

Анализ целей и средств   Использует множество операторов для последовательного решения подзадач до тех пор, пока не будет решена вся задача в целом

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

P Q P

Q

Здесь:

P = Если су щ ествует автобусный маршрут из Детройта в Нью-Йорк, Q = Джон поедет в отпуск.

Мы могли бы спроектировать простой агент обеспечения решения, который позволит нам узнать, поедет Джон в отлуск или нет. Этому агенту нужно узнать все возможное об автобусных маршрутах. Предположим, у нас есть список автобусных маршрутов:

Толедо-Кливленд Детройт-Чикаго Янгстаун-Нью-Йорк

Кливленд-Колумбус Цинциннати-Детройт Детройт-Толедо

Колумбус-Нью-Йорк Цинциннати-Янгстаун

Каждый из этих маршрутов представляет обязательство, взятое на себя компанией ABC Bus Company. Если наш агент получит доступ к расписанию автобусных маршрутов этой компании, то приведенный выше список маршрутов можно будет использовать для представления некоторой части убеждений нашего агента. Возникает вопрос: как перейти от списка маршрутов к убеждениям? Для начала попробуем разработать простую структуру утверждений.

struct existing_trip{

//. . .

string From;

time Departure;

string То;

time Arrival;

//.. .

};

Затем попытаемся использовать контейнерный класс для представления убеждений нашего агента в отношении автобусных маршрутов.

set<existing_trips> BusTripKnowledge ;

Если определенный автобусный маршрут содержится в множестве BusTripKnowledge, то наш агент убежден в том, что в указанное время автобус непременно отправится по этому маршруту из пункта отправления в пункт назначения. Итак, мы можем зафиксировать любой маршрут в соответствии с заданной структурой.

//...

existing__trip Trip;

Trip. From. append (" Toledo " ) ;

Trip.To.append( «Cleveland») ;

Trip.Departure(«4:3 О») ;

Trip.Arrival(«5:45») ;

BusTripKnowledge. insert(Trip) ;

//...

Если мы поместим каждый маршрут в множество BusTripKnowledge, то убеждения нашего агента об автобусных перевозках компании ABC Bus Company будут полностью описаны. Обратите внимание на то, что прямого маршрута из Детройта в Нью-Йорк не существует. Но Джон может добраться в Нью-Йорк из Детройта более сложным путем, осуществив следующие переезды автобусом:

из Детройта в Толедо; из Толедо в Кливленд; из Кливленда в Кол^мбус; из Колумбуса Нью-Йорк.

Поэтому, несмотря на то, что компания ABC Bus Company не предоставляет прямого маршрута (из пункта А в пункт Б), она позволяет совершить переезд с большим количеством промежуточных остановок. Задача состоит в следую щ ем: как об этом может узнать наш агент? Агент на основе своих знаний об автобусных маршрутах должен обладать некоторым алгоритмом генерирования вывода о том, су щ ествует ли маршрут из Детройта в Нью-Йорк. Мы используем простой цепной метод. Просматриваем элементы множества BusTripKnowledge и находим первый маршрут из Детройта— из Детройта в Чикаго. Опрашиваем атрибут То этого элемента. Если бы он был равен значению «Нью-Йорк», процесс поиска был бы прекращен, поскольку мы нашли нужный маршрут. В противном случае сохраняем найденный (промежуточный) маршрут в стеке. Затем ищем маршрут с атрибутом From, равным «Чикаго». При этом может оказаться, что таких маршрутов не прелусмотрено вообще. Поскольку далее хранить элемент множества, соответствующий маршруту «Детройт-Чикаго», нет никакого смысла, мы удаляем его из стека, сделав пометку, что этот маршрут уже был рассмотрен. Затем повторяем поиск маршрута с отправлением из Детройта. Находим такой маршрут: «Детройт-Толедо». Проверяем, не равен ли его атрибут То значению «Нью-Йорк», и поскольку наши надежды не оправдались, сохраняем этот элемент в стеке. Затем ищем маршрут с атрибутом From, равным «Толедо». Находим маршрут «Толедо-Кливленд» и также помещаем его на хранение в стек. После это г о просматриваем маршруты в надежде найти элемент, у которого атрибут From был бы равен значению «Кливленд». Для каждо го найденного маршрута проверяем значение атрибута То. Если он равен значению " Нью-Йорк» , то промежуточные маршруты, помещенные в стек, представляют в целом маршрут из Детройта в Нью-Йорк, начало которого находится на «дне» стека, а его конечный пункт — в вершине. Если мы пройдем по всему списку маршрутов и не найдем ни одного с атрибутом То, равным значению «Нью-Йорк», или иссякнут возможные варианты проверки атрибута То для верхнего элемента стека, то мы, извлекал верхний элемент из стека, будем искать следующий элемент, значение атрибута From которого совпадает со значением атрибута То элемента, расположенного в вершине стека. Этот процесс повторяется до тех пор, пока стек не опустеет или мы все-таки не най дем нужный маршрут. Для определения, существует ли маршрут из пункта А в пункт Б, используется в данном случае упрощ ен ный метод DFS (Depth First Search — «поиск вглубь»).

Наш простой агент будет использовать этот DFS-метод для выяснения, существует ли маршрут из Детройта в Нью-Йорк. Выяснив этот факт, агент может обновить свои убеждения насчет Джона. Теперь агент убежден, что Джон поедет в отпуск. Предположим, мы внесли дополнительное прелусловие относительно отпуска Джона.

Если Джон обслужит 15 или больше новых клиентов, его доходы превысят (>) 150000.

Если доходы Джона превысят 150000 и существует маршрут из Детройта в Нью-Йорк, то Джон отправится в отпуск.

Теперь агент должен выяснить, превышают ли доходы Джона лумму 150000 и существует ли маршрут из Детройта в Нью-Йорк. Чтобы выяснить положение дел насчет доходов Джона, агент должен сначала узнать, обслужил ли Джон хотя бы 15 новых клиентов. Предположим, мы уверяем программного агента в том, что Джон обслужил 23 новых клиента. Затем агент должен убедиться в том, что его доходы превышают 150000. На основе содержимо г о множества BusTripKnowledge агент сумел прийти к выволу о существовании маршрута из Детройта в Нью-Йорк. На основании убеждений об автобусных маршрутах и 23 новых клиентах агент использует процесс прямого построения цепочки (т.е. рассуждений от исходных посылок к целевой гипотезе) и приходит к заключению, что Джон таки поедет в отпуск. Формат рассуж-дений этого процесса имеет такой вид.

А -> В (В и С) -> D А С

D

Здесь:

А=ЕслиДжон обслужит не менее 15 новых клиентов, В = Доходы>150000,

С = Су щ ествует автобусный маршрут из Детройта в Нью-Йорк, D = Джон поедет в отпуск.

В этом примере агент убеждается, что эле м енты А и С истинны. С использование м правил ведения рассуждений агент заключает, что эле м енты В и D равны значению ИСТИНА. Следовательно, агент делает вывод о том, что Джон поедет в отпуск. Подобный вид обработки имеющихся данных можно было бы применить к агенту в ситуации, когда у директора фирмы в подчинении находятся сотни или даже тысячи служащих, и он хотел бы, чтобы агент регулярно составлял почасовой график работы для своих служащих. Директор намерен затем получать от агента справку о том, кто работал, кто находился в отпуске по болезни, а кто — в очередном отпуске и т.д. Агент должен обладать знаниями и полномочиями устанавливать график работы. Каждую неделю агент должен представлять ряд приемлемых графиков работы, очередных отпусков и сведений о пропусках по болезни. Агент в этом случае для получения результата использует простой метод прямого построения цепочки и метод DFS. Чтобы реализовать этот вид рассуждений, мы использовали такие типы данных, как struct и классы стеков и множеств. Эти классы используются для хранения знаний, предположений иметодов рассуждений. Они позволяют реализовать когнитивные структуры данных (Cognitive Data Structures — CDS). Для поддержки процесса рассуждений, а именно при опросе наших структур данных (стека и множества) мы использовали DFS-методы.

При сочетании метода прямого построения цепочки и метода DFS создается процесс, в соответствии с которым одно предположение может быть подтверждено на основе уже принятых предыдущих. Это очень важный момент, поскольку наш агент при достижении цели должен знать, что в действительности следует считать корректным. Такой подход также влияет на отношение к вопросам параллельного программирования. Тот факт, что агент рационален и действует в соответствии с правилами построения рассуждений, позволяет разработчику сосредоточиться на корректном моделировании задачи, выполняемой агентом, а не на стремлении явно управлять параллелизмом в программе. Минимальные требования параллелизма, выражаемые тремя «китами» — декомпозицией, взаимодействием и синхронизацией (decomposition, communication, synchronization — DCS), — по большей части относятся к архитектуре агента. Каждый агент для своего поведения имеет логическое обоснование. Это обоснование должно опираться на хорошо определенные и хорошо понимаемые правила ведения рассуждений. Декомпозиция зачастую выражается в простом назначении агенту одного или нескольких основных указаний (директив). Декомпозиция работ в этом случае должна иметь естественный характер и в конце концов выразиться в параллельных или распределенных программах, которые нетрудно поддерживать и развивать. Взаимодействие агентов проще представить, чем взаимодействие анонимных модулей , поскольку границы между агентами более четки и очевидны. Каждый агент имеет цель, которая лежит на поверхности. Знания, или информация, необходимые каждому агенту для достижения его цели, в этом случае легко определяются. Чтобы позволить агентам взаимодействовать, разработчик может использовать простые MPI-функции или средства взаимодействия объектов, которые являются частью любой CORBA-реализации. При обеспечении взаимодействия агентов самыми сложными являются следующие моменты:

• посредством чего должно происходить взаимодействие;

• кому нужно взаимодействовать;

• когда должно происходить взаимодействие;

• какой формат должно иметь взаимодействие.

Ответы на эти вопросы должны быть изначально заложены в проект агентов. Теперь осталось лишь определиться с физической реализацией взаимодействия агентов. Для этого можно воспользоваться библиотеками, которые поддерживают параллелизм. Наконец, что касается проблем синхронизации, то с ними можно легко справиться, поскольку именно логическое обоснование агента сообщает ему, когда он может и должен выполнять действия. Следовательно, сложные вопросы синхронизации сводятся к простым вопросам сотрудничества. Благодаря этому упрощается и задача разработчика в целом. Теперь рассмотрим базовую структуру агента и возможности его реализации в С++.

Реализация агентов в С++

Рассмотрим упрощенный вариант предыдущего примера агента и продемонстрируем, как его можно реализовать в С++. Цель этого агента — составлять график отпусков и выполнять подготовку к поездкам владельца компании ABC Auto Repair Company. В компании работают десятки служащих, и поэтому у хозяина нет времени заботиться о проведении своего очередного отпуска. Кроме того, если хозяин не получит определенного объема прибыли, об отпуске не может быть и речи. Поэтому владельцу компании хотелось бы, чтобы агент распланировал его отпуска равномерно по всему голу при условии процветания фирмы. По мнению владельца компании, главное, чтобы агент работал автоматически, т.е. после инсталляции на компьютере о нем можно было не беспокоиться. Когда агент определит, что подошло время для отпуска, он должен предъявить план проведения отпуска, забронировать места в отеле и проездные билеты, а затем по электронной почте представить хозяину маршрут. Владелец должен побеспокоиться только о формировании задания для агента. Он должен указать, куда желает отправиться и какой объем прибыли необходимо получить, чтобы запланированная поездка состоялась. Теперь рассмотрим, как можно спроектировать такой агент. Вспомним, что рациональный компонент (см. рис. 12.1) класса агента состоит из когнитивных структур данных и методов рассуждений (стратегий логического вывода). Когнитивные структуры данных (CDS) позволяют хранить убеждения, предположения, знания, заблуждения, факты и пр. Для доступа к этим когнитивным структурам данных в процессе решения проблемы и выполнения задач класс агента использует стратегии логического вывода. Для реализации CDS-структур данных и методов построения рассуждений можно использовать ряд контейнерных классов и алгоритмов, которые содержатся в стандартной библиотеке С++.

Типы данных предположений и структуры убеждений

Этот агент обладает убеждениями о показателях авторемонтной мастерской. Убеждения составляют информацию о том, сколько клиентов обслуживается в час, какова загрузка ремонтных секций в день и общий объем продаж (запчастей и услуг) за некоторый период времени. Кроме того, агент знает, что владелец фирмы любит путешествовать только автобусами. Поэтому агент хранит информацию об автобусных маршрутах, которые могут для отпускника оказаться привлекательными. В программе, насыщенной математическими вычислениями, используются в основном целочисленные значения и числа с плавающей точкой. В графических программах участвуют пиксели, линии, цвета, геометрические фигуры и пр. В агентно-ориентированной программе основными типами данных являются предположения, правила, утверждения, литералы и строки. Для построения типов данных, свойственных агентно-ориентированному программированию, мы будем опираться на объектно-ориентированную поддержку, прелусмотренную в С++. Итак, рассмотрим объявление класса предположения (листинг 12.1).

// Листинг 12.1. Объявление класса предположения

template<class C> class proposition {

//...

protected:

list<C> UniverseOfDiscourse;

bool TruthValue; public-virtual bool operator()(void) = О;

bool operator&&(proposition &X);

bool operator||(proposition &X);

bool operator||(bool X);

bool operator&&(bool X);

operator void*();

bool operator!(void);

bool possible(proposition &X);

bool necessary(proposition &X);

void universe(list<C> &X);

//.. .

};

Предположение представляет собой утверждение, тема (предмет) которого подтверждается или отрицается предикатом. Предположение может принять значение ИСТИНА или ЛОЖЬ. Предположение можно использовать для фиксации одного убеждения, которое есть у агента. Кроме того, в качестве предположения может быть представлена некоторая другая информация, которая предлагается агенту и которую агент необязательно воспринимает как убеждение. Для представления предположений используется когнитивный тип данных, который должен быть таким же функциональным в агентно-ориентированной программе, как целочисленные и вещественные типы данных в математических программах. Поэтому, чтобы обеспечить некоторые основные операторы, применимые к предположениям, мы используем C++-средства перегрузки операторов. В табл. 12.4 показано, как такие операторы преобразуются в логические.

Класс proposition (см. листинг 12.1) представляет собой упрощенную версию (с сокращённым набором функциональных возможностей). Назначение этого класса— сделать использование типа данных proposition таким же простым и естественным, как использование любого другого С++-типа данных. Обратите внимание на слелующее объявление в классе proposition: virtual bool operator()(void) = 0;

Таблица 12.4. Преобразование операторов влогические

Пользовательские C++onepamopы   Распространенныелогические операторы

&& ^

|| v

! ~

possible  ♦

necessary  □

Это объявление чисто виртуального метода. Если в классе объявлен чисто виртуальный метод, это означает, что данный класс — абстрактный, и из него нельзя создавать объекты, поскольку в нем отсутствует определение этого метода. Метод лишь объявлен, но не определен. Абстрактные классы используются для определения стратегий и являются своего рода проектами производных классов. Производный класс должен определить все виртуальные функции, которые он наслелует от абстрактного класса. В данном случае класс proposition используется для определения минимального набора возможностей, которыми может обладать класс-потомок. Необходимо также отметить еще одну важную особенность класса proposition (см. листинг 12.1): это шаблонный класс. Он содержит такой член данных: list<C> UniverseOfDiscourse;

Этот член данных предполагается использовать для хранения значения предметной области, к которой относится предположение. В логике область рассуждения содержит все легальные сущности, которые могут рассматриваться при обсуждении. Здесь мы используем контейнер list. Поскольку в общем случае темы обсуждения могут быть самыми разными, мы используем контейнерный класс. Список UniverseOfDiscourse мы объявляем защищенным (protected), а не закрытым (private), чтобы к нему могли получить доступ все потомки класса proposition. Классу proposition также «знакомы» такие понятия модальной логики, как логическая необходимость и вероятность, которые весьма полезны в агентно-ориентированном программировании. Модальнал логика позволяет агенгу различать такие определения, как «вероятно, ИСТИНА» и «несомненно, ИСТИНА». Основные операторы, используемые для выражения логической необходимости и вероятности, перечислены в табл. 12.4. Мы определяем эти методы только в описательных целях; их реализация выходит за рамки рассмотрения в этой книге. Но они являются частью классов предположений, которые мы успешно применяем на практике. Чтобы сделать класс proposition «годным к употреблению», выведем из него новый класс и назовем его trip_announcement. Класс trip_announcement представляет собой утверждение о существовании автобусного маршрута из некоторого исходного пункта (отправления) в пункт назначения. Например, предположим, что существует автобусный маршрут из Детройта в Толедо. Эта информация позволяет сформулировать высказывание, которое может быть либо истинным, либо ложным. Если бы нас интересовало, когда это высказывание истинно или ложно, мы бы воспользовались понятиями временной логики. Временняя логика— это логика времени. Агенты также применяют обоснования, зависящие от времени. Но в данном случае все предположения относятся к текущему времени. Это утверждение декларирует, что в данное вре м я существует автобусный м аршрут из Детройта в Толедо. Агент должен «у м еть» удостовериться в этом и либо «довериться» это м у факту, либо отвергнуть его как ложное высказывание. Теперь м ожно расс м отреть объявление класса trip_armouncement, представленное в листинге 12.2.

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

class trip_announcement :

publiс proposition<trip_announcement>{

//.. .

protected:

string Origin; string Destination;

stack<trip_announcement> Candidates; public:

bool operator()(void);

bool operator==(const trip_announcement &X) const;

void origin(string X);

string origin(void);

void destination(string X);

string destination(void);

bool directTrip(void);

bool validTrip(list<trip_announcement>::iterator I,

string TempOrigin);

stack<trip_announcement> candidates(void);

friend bool operator||(bool X,trip_announcement &Y);

friend bool operator&&(bool X,trip_announcement &Y);

//. . .

};

Обратите вни м ание на то, что класс trip_armouncement наследует класс proposition. Вспо м ните, что класс proposition является шаблонным и требует задания параметра, определяющего тип. Объявление

class trip_announcement :

public proposition<trip_announcement>

{... } ;

обеспечивает класс proposition требуе м ы м типо м. Кро м е того, важно от м етить, что класс trip_announcement определяет операторный м етод operator (). Следовательно, наш класс trip_armouncement — конкретный, а не абстрактный. Теперь мы можем объявить и использовать предположение типа trip_announcement непосредственно в программе агента. В классе trip_announcement определены слелую-щие дополнительные члены данных: Origin Destination Candidates

Эти члены данных используются для указания пунктов отправления и назначения автобусного маршрута. Если автобусный маршрут требует пересадки с одного автобуса надругой и несколько остановок в пути, то член данных Candidates будет содержать полный путь следования. Следовательно, объект класса trip_armouncement представляет собой утверждение об автобусном маршруте и пути следования. В классе trip_armouncement также определены некоторые дополнительные операторы. Эти операторы позволяют уравнять класс trip_announcement «в правах» со встроенны м и типа м и данных языка С++. Помимо убеждений относительно автобусных м аршрутов, агент также обладает убеждения м и, связанны м и с показателя м и успешности функционирования расс м атривае м ой ко м пании. Эти убеждения отличаются по структуре, но в основном содержат высказывания, которые могут быть истинными либо ложными. Итак, мы снова испо л ьзуе м класс proposition в качестве базового. Влистинге 12.3 представлено объявление класса p eformance_statement.

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

class performance__statement :

public proposition<performance_statement>{

//. . .

int Bays;

float Sales;

float PerHour;

public:

bool operator() (void);

bool operator==(const performance__statement &X) const;

void bays(int X);

int bays(void);

float sales(void);

void sales(float X);

float perHour(void);

void perHour(float X);

friend bool operator||(bool X,performance_statement &Y);

friend bool operator&&(bool X,performance_statement &Y); //. . .

};

Обратите вни м ание на то, что этот класс также обеспечивает шаблонный класс proposition параметром .

class performance_statement :

public proposition<performance__statement> {...}

Благодаря это м у объявлению класс proposition теперь определен д ля объектов типа performance_statement. Класс performance_statement используется для представления убеждений об объе м е продаж, количестве обслуженных клиентов (в час) и загрузке ре м онтных секций в день. Для каждого из перечисленных убеждений о том, что агент имеет в соответствующей области, существует отдельное высказывание. Эта инфор м ация хранится в таких членах данных:

Bays

Sales

PerHour

Такие высказывания, как «По секции 1 объе м продаж составил 300тыс. долл., обслужено 10 клиентов в час, а коэффициент загрузки равен 4», м ожно представить с по м о щ ью объекта класса performance_statement. Итак, наш класс агента и м еет две категории убеждений, реализованных в виде данных, тип которых выведен из класса proposition. На рис. 12.2 представлена UML-диагра мм а классов trip_announcement и performance__statement. Эти классы предназначены для хранения структуры убеждений агента.

Рис. 12.2. UML-диаграмма классов trip_announcement и performance_statement

Класс агента

Классы, представленные на рис. 12.2, образуют фундаментдля когнитивных структур данных агента, которые делают агента рациональным. Именно рационализм класса агента отличает его от других типов объектно-ориентированных классов. Рассмотрим объявление класса агента, приведенное в листинге 12.4.

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

class agent{

//.. .

private:

performance_statement Manager1;

performance_statement Manager2;

performance_statement Manager3;

trip_announcement Trip1;

trip_announcement Trip2;

trip_announcement Trip3;

list<trip_announcement> TripBeliefs;

list<performance_statement> PerformanceBeliefs;

public:

agent(void);

bool determineVacationAppropriate(void);

bool scheduleVacation(void);

void updateBeliefs(void);

void setGoals(void);

void displayTravelPlan(void);

//.. .

} .

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

li s t<trip_announcement> TripBeliefs;

list<performance_statement> PerformanceBeliefs;

Контейнеры типа list — это стандартные С++-списки. Каждый список используется для хранения коллекции текущих убеждений агента. «Мировоззрение» нашего простого агента ограничено знаниями об автобусных маршрутах и характеристиках успешности его владельца. Содержимое этих двух контейнеров представляет полные знания агента и набор его убеждений. Если в этих списках есть утверждения, в которые агент больше не верит, их следует удалить. Если в процессе рассуждений агент обнаруживает новые утверждения, они добавляются в список уже существующих убеждений. Агент имеет постоянный доступ к информации об автобусных маршрутах и эффективности ведения бизнеса его владельца и при необходимости может обновлять свои убеждения. Помимо убеждений, агент имеет цели, которые иногда представляются как желания в модели убеждений, желаний и намерений (Beliefs, Desires, Intentions — BDI). Цели поддерживают основные директивы, выдаваемые агенту клиентом. В нашем случае цели сохраняются в высказываниях, приведенных ниже.

performance_statement Manager1;

performance_statement Manager2;

performance_statement Manager3;

trip_announcement Trip1;

trip_announcement Trip2;

trip_announcement Trip3;

С л едует иметь в виду, что мы значительно упрощаем представление целей и директив в классе агента. Но все же этого достаточно, чтобы понять, как построены эти структуры. Три Manager -утверждения содержат цели, связанные с эффективностью бизнеса, которые должны быть удовлетворены, прежде чем владелец фирмы сможет хотя бы подумать об отпуске. Три Trip -утверждения содержат автобусные маршруты, по которым владелец фирмы хотел бы прокатиться при условии успешности его бизнеса. Убеждения вместе с директивами образуют базовые когнитивные типы данных, которыми располагает агент. Используемые агентом стратегии логического вывода вместе с этими когнитивными типами данных образуют когнитивную структуру данных агента (Cognitive Data Structure — CDS). На базе CDS <TpyKrypbi формируются рациональный компонент и характерные особенности класса агента. Помимо контейнеров, в которых хранятся убеждения и структуры, которые в свою очередь хранят директивы и цели, большинство классов агентов имеют контейнеры, предназначенные для хранения намерений, обязательств или планов агента. Агент получает директивы от своего клиента, а затем использует свою способность делать выводы и совершать действия, направленные на выполнение этих директив. Результат рассуждений и выполнения агентом действий часто сохраняется в контейнере с его намерениями, обязательствами или планами. Что касается нашего простого агента, то для хранения намерений или планов отдельного контейнера не ему требуется. Однако он должен зафиксировать путь следования (с пересадками и остановками) предполагаемой отпускной поездки на автобусе. Эта информация хранится в контейнере Candidates.

Намерения или планы должны быть обработаны аналогичным образом. Если агент может выполнить директивы, он распланирует поездку и по электронной почте подробно сообщит об этом своему владельцу. Агент приступает к своим обязанностям в момент создания объекта. Фрагмент конструктора агента представлен в листинге 12.5

// Листинг 12.5. Конструктор класса agent

agent: :agent(void) {

setGoals();

updateBeliefs () ;

if(determineVacationAppropriate()){

displayTravelPlan(); scheduleVacation();

cout « «Сообщение о возможности отпуска.» « endl;

} else {

cout « «В данное время отпуск нецелесообразен.» « endl;

}

Цикл активизации агента

Многие определения агентов включают требования непрерывности и автономности. Идея состоит в том, что агент должен непрерывно выполнять поставленные перед ним задачи без вмешательства оператора. Агент обладает способностью взаимодействовать со своей средой и (до некоторой степени) контролировать ее благодаря наличию цепи обратной связи. Непрерывность и автономность часто реализуются в виде событийного цикла, при выполнении которого агент постоянно получает сообщения и информацию о событиях. Эти сообщения и события агент использует для обновления своей внутренней модели мира, намерений и предпринимаемых действий. Однако непрерывность и автономность — понятия относительные. Одни агенты должны активизироваться каждую микросекунду, в то время как другие — лишь один раз в год. А в случае программного обеспечения полетов в дальний космос агент может иметь цикл даже больше одного года. Поэтому мы не будем акцентировать внимание на физических событийных циклах и постоянно активных очередях сообщений. Такая организация может подходить для одних агентов, но оказаться непригодной для других. Мы пришли к выводу, что лучше всего здесь применить понятие логического цикла. Логический цикл может (или не может) быть реализован как событийный. Логический цикл может длиться от одной наносекунды до некоторого количества лет. Общий вид простого логического цикла активизации агента показан на рис. 12.3.

Область рассуждения (см. рис. 12.3) представляет все, с чем наш агент может легитимно взаимодействовать. Эта область может состоять из файлов, информации от портов или устройств сбора данных. Получаемая информация должна быть представлена в виде предположений или утверждений (высказываний). Обратите внимание на существование цепи обратной связи от выходных данных агента к входным. Наш агент (см. листинг 12.4) активизируется только несколько раз в год. Следовательно, нет смысла помещать его в постоянно выполняющийся событийный цикл. Наш агент должен периодически активизироваться в течение года для выполнения своих задач. В листинге 12.5 представлен конструктор агента. При активизации агент устанавливает цели, обновляет убеждения, а затем определяет уместность отпуска. Если отпуск возможен, агент предпринимает некоторые действия и по электронной почте уведомляет об этом владельца фирмы. Если же отпуск в данное время нецелесообразен, владелец получает от агента сообщение другого содержания.

Рис. 12.3. Общий вид простого логического цикла активизации агента

12.4.2.2. Стратегии логического вывода агента

Этот агент обладает способностями рассуждать, реализованными частично классом proposition и частично м етодо м determineVacationAppropriate() . Вспомните, что в классе proposition объявлен метод operator() =0 в виде чисто виртуальной функции. Поэто м у в производно м к л ассе необходи м о реализовать м етод operator (). Мы используем этот оператор, чтобы объект предположения мог самостоятельно определить свою «суть», т. е. понять, истинно данное предположение или ложно. Это означает самодостаточность классов предположений. Именно в самодостаточности и состоит фундаментальный принцип объектно-ориентированного программирования: класс представляет собой самостоятельную конструкцию, инкапсулирующую его характеристики и поведение. Итак, одной из основных линий поведения класса предположений и его потомков является способность определять, истинно данное предположение или нет. Для реализации этого средства используется перегрузка операторов и объекты-функции. Рассмотри м фрагменты определения класса proposition и определений его потомков.

//Листинг 12.6. Фрагменты определений класса

// proposition и его потомков

template <class C> bool proposition<C>::operator&&(

proposition &X)

{

return((*this)() &&X());

template <class C> bool proposition<C>::operator||(

proposition &X)

{

return((*this)() || X());

template<class C> proposition<C>::operator void*(void) {

return((void*)(TruthValue));

bool trip__announcement::operator()(void) {

list<trip_announcement>::iterator I; if(directTrip()){

return(true);

}

I = UniverseOfDiscourse.begin();

if(validTrip(I,Origin)){

return(true);

}

return(false);

}

Операторы "||" и "&&", используемые в классах предположений, позволяют определить, истинно данное предположение или ложно. В каждом из этих определений операторов в конечном счете вызывается метод operator () , определенный в классе-потомке. Обратите внимание на определение оператора "||" (см. листинг 12.6). Этот оператор определен следующим образом.

template <class C> bool proposition<C>::operator||

(proposition &X)

{

return((*this)() || X());

}

Это определение позволяет использовать следующий код.

trip_announcement А;

performance_statement В;

if (А || В) {

// Какие-нибудь действия.

}

При вычис л ении выражений А или В будет вызван оператор operator (). Каждый класс предположений определяет поведение оператора operator () по своему. Напри м ер, в классе trip_announcement оператор operator () определяется так.

bool trip_announcement::operator()(void) {

list<trip_announcement>::iterator I;

if(directTrip()){

return(true);

}

I = UniverseOfDiscourse.begin();

if(validTrip(I, Origin)){

return(true);

}

return(false);

}

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

Детройт - Толедо

Толедо - Колу м бус

Тогда объект класса trip_announcement «доложит» о то м, что утверждение о су щ ествовании автобусного м аршрута из Детройта в Колу м бус истинно, нес м отря на то, что область рассуждений не содержит утверждения о пря м о м маршруте:

Детройт - Колу м бус

Объект класса trip_announcement действительно проверит, существует ли прямой маршрут из Детройта в Колумбус. Если он существует, объект возвратит значение ИСТИНА. В противном случае он попытается найти обходной путь. Подобное поведение реализуется так.

if(directTrip()){

return(true);

}

I = UniverseOfDiscourse.begin();

if(validTrip(I,Origin)){

return(true);

}

«Самоопределением» истинности объект обязан оператору operator () класса trip_anouncement. Метод directTrip () довольно прост, и его работа заключается в последовательном просмотре области рассуждений на предмет существования следующего утверждения:

Детройт - Колу м бус

Метод validTrip () , чтобы узнать, существует ли обходной путь, использует технологию поиска вглубь (Depth First Search— DFS). Определения методов validTrip () и directTrip () приведены в листинге 12.7.

// Листинг 12.7. Определения методов validTrip() и // directTrip()

bool trip_announcement::validTrip(list<trip_announcement>::iterator I, string TempOrigin)

{

if(I == UniverseOfDiscourse.end()){ if(Candidates.empty()){ TruthValue = false; return(false);

}

else{

trip_announcement Temp; Temp = Candidates.top(); I = find(UniverseOfDiscourse.begin(), UniverseOfDiscourse.end(),Temp); UniverseOfDiscourse.erase(I); Candidates.pop(); I = UniverseOfDiscourse.begin(); if(I != UniverseOfDiscourse.end()){ TempOrigin = Origin;

} else {

TruthValue = false; return(false);

}

}

>

if((*I).origin() == TempOrigin &&

(*I).destination() == Destination){ Candidates.push(*I); TruthValue = true; return(true);

}

if((*I).origin() == TempOrigin){ TempOrigin = (*I).destination(); Candidates.push(*I);

}

I++;

return(validTrip(I,TempOrigin));

bool trip_announcement: :directTrip(void) {

list<trip_announcement>::iterator I; I = find(UniverseOfDiscourse.begin(),

UniverseOfDiscourse.end(), *this); if(I == UniverseOfDiscourse.end()){

TruthValue = false;

return(false);

}

TruthValue = true; return(true);

В обоих методах validTrip () и directTrip () используется алгоритм find() из стандартной библиотеки С++. UniverseOfDiscourse — это контейнер, который содержит убеждения агента и подготовленные для него утверждения. Вспомните, что одним из первых действий, предпринимаемых агентом, является вызов метода updateBeliefs(), который заполняет контейнер UniverseOfDiscourse. Определение метода updateBeliefs () приведено в листинге 12.8.

// Листинг 12.8. Обновление убеждений

void agent::updateBeliefs(void) {

performance_statement TempP;

TempP.sales(203.0);

TempP.perHour(10 0.0);

TempP.bays(4);

PerformanceBeliefs.push_back(TempP);

trip_announcement Temp;

Temp.origin(«Detroit»);

Temp.destination(«LA»);

TripBeliefs.push_back(Temp);

Temp.origin(«LA»);

Temp.destination(«NJ»);

TripBeliefs.push_back(Temp);

Temp.origin(«NJ»);

Temp.destination(«Windsor»);

TripBeliefs.push_back(Temp);

}

На практике убеждения обычно поступают из среды выполнения агента ( т.е. из файлов, от датчиков, портов, устройств сбора данных и пр.). В листинге 12.8 инфор м ация, поступающая в списки TripBeliefs и PerformanceBeliefs, представляет новые высказывания, которые агент получает о приемлемых маршрутах и эффективности авторемонтной мастерской. Эти высказывания оцениваются относительно директив, выданных агенту. Установкой директив агента зани м ается м етод setGoals (). (Его опреде л ение приведено в л истинге 12.9.)

// Листинг 12.9. Метод установки целей агента

void agent::setGoals(void) {

Managerl.perHour(15.0);

Managerl.bays(8);

Managerl.sales(123.2 3);

Manager2.perHour(2 5.3 4);

Manager2.bays(4);

Manager2.sales(12.33);

Manager3.perHour(3 4.3 4);

Manager3.sales(100000.12);

Manager3.bays(10);

Trip1.origin(«Detroit»);

Tripl.destination(«Chicago»);

Trip2.origin(«Detroit»);

Trip2.destination(«NY»);

Trip3.origin(«Detroit»);

Trip3.destination(«Windsor»);

}

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

Этот метод передает контейнер UniverseOfDiscourse каждому из объектов предположен и й. После это г о он использует утверждение, выраженное в следую щ ей форме: (А v В v С) ^ (Q v R v S) --> W

Это выражение можно озвучить так: если хотя бы одно из утверждений каждой группы истинно, то элемент W примет значение ИСТИНА. Для наше г о а г ента это означает, что если дости г нута хотя бы одна из целей эффективности бизнеса и существует хотя бы один из приемлемых автобусных м аршрутов, то отпуск м ожно планировать. Определение м етода determineVacationAppropriate () представлено в листинге 12.10.

// Листинг 12.10. Второй метод рассуждений

bool agent::determineVacationAppropriate(void) {

bool TruthValue;

Managerl.universe(PerformanceBeliefs);

Manager2.universe(PerformanceBeliefs);

Manager3.universe(PerformanceBeliefs);

Tripl.universe(TripBeliefs);

Trip2.universe(TripBeliefs);

Trip3.universe(TripBeliefs);

TruthValue = ((Managerl || Manager2 || Manager3) &&

(Tripl || Trip2 || Trip3)); return(TruthValue);

}

Обратите внимание на то, что списки TripBeliefs и PerformanceBeliefs являются аргументами метода universe() объектов Trip и Manager. Именно здесь объекты предположений получают информацию из предметной области (UniverseOfDiscourse). Прежде чем объект класса proposition вызовет оператор operator(), его контейнер UniverseOfDiscourse должен заполниться имеющимися у агента данными. В листинге 12.10 при вычислении выражения

((Managerl || Manager2 || Manager3) && (Tripl || Trip2 || Trip3));

оценивается шесть предположений (посредством выполнения оператора "||"). Оператор " | |" для каждого предположения выполняет оператор operator (), который для определения истинности предположения использует список UniverseOfDiscourse. Слелует иметь в виду, что классы trip_announcement Hperformance_statement наследуют довольно много функций класса proposition. В листингах 12.6 и 12.7 было показано, как определяется оператор operator() для класса trip_announcement, а в листинге12.11 приведено определение оператора operator () для класса performance_statement.

// Листинг 12.11. Класс performance_statement

bool performance_statement::operator()(void) {

bool Satisfactory = false;

list<performance_statement>::iterator I;

I = UniverseOfDiscourse.begin();

while(I != UniverseOfDiscourse.end() && !Satisfactory) {

if(((*I).bays() >= Bays) || ((*I).sales() >= Sales)

|| ((*I).perHour() >=PerHour)){ Satisfactory = true;

}

I++;

}

return(Satisfactory);

}

Оператор operator () для каждого класса proposition играет «свою» роль в способности класса агента делать логические выводы. В листинге 12.6 показано, как вызывается оператор operator () при каждом вычислении оператора " || " или "&&" для класса proposition или для одного из его потомков. Именно такое сочетание методов operator (), определенных в proposition-классах, и методов класса agent образует стратегии логического вывода для класса agent. В дополнение к операторам "||" и "&&", определенным в классе proposition, классы trip_announcement и performance_statement содержат свои определения.

friend bool operator||(bool X,trip_announcement &Y); friend bool operator&&(bool X,trip_announcement &Y);

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

//. . .

trip_announcement А, В, С; bool X;

X = А || В || С;

//.. .

При этом объекты А и В будут объединены с помощью операции ИЛИ, а результат этой операции будет иметь тип bool. Затем мы попробуем с помощью той же операции ИЛИ получить значение типа bool и объект типа trip_announcement: bool || trip_announcement

Без приведенных выше friend -объявлений такая операция была бы недопустимой. Определение этих функций-«друзей» показано влистинге 12.12.

// Листинг 12.12. Перегрузка операторов "||" и "&&"

bool operator||(bool X,trip_announcement &Y) {

return(X | | YO) ;

}

bool operator&&(bool X,trip_announcement &Y) {

return(X && Y());

}

Обратите внимание на то, что в определении этих функций-«друзей» (благодаря ссылке на элемент Y ()) также используется вызов функции operator (). Эти функции определяются и в классе performance_statement. Наша задача — сделать использование proposition-классов таким же простым, как использование встроенных типов данных. В классе proposition также определен другой оператор, который позволяет использовать предположение естественным образом. Рассмотрим следующий код.

//.. .

trip_announcement А; if(A) {

//... Некоторые действия.

}

//.. .

Как в этом случае компилятор тестирует объект А? При выполнении инструкции if () компилятор стремится найти в скобках значение целочисленного типа данных или типа bool. Но тип объекта А совсем другой. Мы хотим, чтобы ко м пилятор восприни м ал объект А как высказывание, которое м ожет быть либо истинны м, либо ложны м. При таких обстоятельствах функция operator () не вызывается. Поэто м у для получения нужного эффекта м ы определяем оператор void*. Эту функцию-оператор можно определить следующим образом.

template<class C> proposition<C>::operator void*(void) {

return((void*)(TruthValue));

}

Это определение позволяет предположение любого типа, представленное «в единственном числе», протестировать как значение истинности. Например, когда наш класс agent собирается отправить по электронной почте владельцу фирмы сообщение, содержащее путь следования, агенту нужно определить, какой маршрут отвечает заданным требованиям. В листинге 12.13 представлен еще один фрагмент из методов обработки автобусных маршрутов.

// Листинг 12.13. Метод displayTravelPlan()

void agent::displayTravelPlan(void) {

stack<trip_announcement> Route;

if(Tripl){

Route = Tripl.candidates();

}

if(Trip2){

Route = Trip2.candidates();

}

if(Trip3){

Route = Trip3.candidates();

}

while(!Route.empty()) {

cout << Route.top().origin() << " TO "« Route.top().destination() « endl; Route.pop();

}

Обратите внимание на то, что объекты Tripl, Trip2 и Trip3 тестируются так, как будто они имеют тип bool. Метод candidates () просто возвращает путь следования, соответствующий заданному маршруту. Таким образом, разработка стратегий логического вывода и когнитивных структур данных становится проще благодаря использованию перегрузки операторов и С++-шаблонов. Именно стратегии логического вывода и когнитивные структуры данных делают объект рациональным. C++-программист для разработки агентов использует конструкцию класса, а для реализации когнитивных сгруктур данных (CDS) — контейнерные объекты в сочетании со встроенными алгоритмами. Класс, который содержит CDS-структуры, становится рациональным, а рациональный класс — агентом.

Простая автономность

Поскольку наш простой класс агента не требует выполнения традиционного «цикла активизации», нам нужны другие средства, которые бы периодически активизировали агент без вмешательства человека. Возможны ситуации, когда агент нужно запускать на выполнение лишь иногда или только при определенных условиях. Среды UNIX/Linux оснащены утилитой crontab, которая представляет собой пользовательский интерфейс «хрон-систе м ы» (xpon— это де м он ОС UNIX, исполняющий предписанные команды в соответствии со строго определенными значениями даты и времени, указанными в спе циально м файле с именем crontab). Утилита crontab позволяет организовать периодическое выполнение одной или нескольких программ. Задания для утилиты crontab можно назначать с указанием месяца, дня недели, дня (месяца), часов и минут. Для использования утилиты crontab в нашем случае необходимо создать текстовый файл, который будет содержать график активизации агента. Записи этого файла должны иметь следующий формат:

м инуты часы день м есяц день недели ко м анда

Каждый эле м ент записи м ожет прини м ать следую щ ие значения:

минуты 0-59

часы 0-23

день 1-31

месяц 1-12

день недели 1-7 (1 — понедельник, 7 — воскресенье)

команда может быть любой UNIX/Linux-командой, а также именем файла,

который содержит агенты

Созданный в таком формате текстовый файл передается «хрон-системе» с помощью слелующей команды:

$crontab  NameOfCronFile

Например, предположи м, у нас есть файл activate.agent, содержи м ое которо г о и м еет такой вид.

15   8   *   *   *   agentl

0   21   *   *   6   agent2

*   *   1   12   *   agent3

После выпол н ения crontab-ко м анды $crontab activate.agent

агент agentl будет активизироваться каждый день в 8:15, агент agent2 — каждое воскресенье в 21:00, а агент agent3— каждый раз при наступлении первого декабря. Хрон-файлы можно при необходимости добавлять или удалять. Хрон-файлы могут содержать ссылки на другие хрон-задания, позволяя таким образом агенту «самому» перепланировать свою работу. Так, для обеспечения чрезвычайно гибкой, динамичной и надежной процедуры активизации агентов можно использовать сценарии оболочки в сочетании с утилитой crontab. Чтобы получить полное описание утилиты crontab, обратитесь к оперативным страницам руководства (manpages— г ипертекстовые страницы консультативной инфор м ации, поясняю щ ие действие конкретных ко м анд): $man crontab или $man at

Средства crontab и at представляют собой простейший способ автоматизации или регулярного запуска агентов, который не требует постоянного выполнения циклов активизации. Эти утилиты надежны и гибки. Однако для реализации автоматической активизации агента также можно использовать хранилище, или репозиторий, реализаций и брокер объектных запросов (object request brokers — ORB), который мы рассматривали в главе 8. Стандартные CORBA-реализации также предоставляют средства организации событийных циклов.

12.5. Мультиагентные системы

Мультиагентные системы— это системы, в которых задействовано несколько агентов, обладающих способностью в процессе решения некоторой задачи взаимодействовать, сотрудничать, «договариваться» или соперничать. У С++-разработчика программного обеспечения есть несколько вариантов для реализации мультиагентных систем. Агенты можно реализовать в отдельных потоках выполнения с помощью API-интерфейса POSIX thread. В этом случае одна программа разбивается на несколько потоков, каждый из которых содержит один или несколько агентов. Следовательно, агенты одного потока будут разделять одно и то же адресное пространство. Это позволяет агентам легко взаимодействовать путем использования глобальных переменных и простой передачи параметров. Если компьютер, на котором выполняется программа, содержит несколько процессоров, то агенты могут выполняться параллельно. В этом случае каждый агент должен быть оснащен объектами синхронизации (см. главы 5 и 11) и компонентами обработки исключительных ситуаций (см. главу7). Мультиагентные системы, реализованные посредством многопоточности, представляют самое простое решение, но тем не менее ограничивающее агентов рамками одного компьютера. Более гибкий подход к созданию мультиагентных систем предоставляет CORBA-реализация. Стандарт CORBA (помимо ядра спецификации CORBA) содержит спецификацию мультиагентного средства (multi-agent facility— MAF). MICO-реализацию, которую мы используем в CORBA-примерах этой книги, можно применять для реализации агентов, которые способны взаимодействовать через сети Internet, intranet и локальные сети. С++-привязка CORBA-стандарта имеет полную поддержку объектно-ориентированного представления и, следовательно, поддержку агентно-ориентированного программирования. В главе 13 мы рассмотрим, как можно использовать библиотеки PVM и MPI для поддержки агентов в контексте параллельного и распределенного программирования.

12.6. Резюме

Агенты — это рациональные объекты. Агентно-ориентированное программирование — это свежий взгляд на старые проблемы декомпозиции, взаимодействия и синхронизации, которые являются обязательной частью каждого проекта параллельного или распределенного программирования. С++-поддержка перегрузки операторов контейнеров и шаблонов обеспечивает эффективные средства реализации широкого диапазона классов агентов. Будущие системы с массовым параллелизмом и большие распределенные системы будут опираться на агентно-ориентированные реализации поскольку практически не существует других путей построения таких систем. Несмотря на «вводный» характер примеров создания агентов, представленных в этой главе, они вполне обеспечивают основу для понимания практических принципов построения агентных систем. Для развертывания мультиагентных систем можно использовать об щ е д оступные и популярные библиотеки POSIX thread API, MICO, PVM и MPI. Мультиагентные системы можно использовать д ля реализации решений, которые требуют параллельного или распределенного программирования. В этой книге представлены два основных варианта архитектуры для параллельного и распределенного программирования: первый представляют агенты, а второй — «классные доски» (которые предполагают использование агентов). О том, как использовать «классные доски» для реализации решений параллельного и распределенного программирования, мы поговорим в следующей главе.

Реализация технологии «классной доски» с использованием PVM-средств, потоков и компонентов

«Человеческий разум гораздо сложнее, чем любой компьютер, но будущая цель развития компьютерной техники — достичь уровня «мышления» не отдельного индивидуума, а умственного потенциала целого общества...»

Тимоти Фeppиc(Timothy Ferhs), The Universe and Eye

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

Модель «классной доски»

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

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

Решатель задач — это про г раммное средство, которое обычно обладает специальными знаниями или возможностями обработки получаемой информации в пределах некоторой предметной области. Решатель задач может быть довольно простой функцией, которая, например, переводит значение температуры по Цельсию в значение по Фаренгейту, или достаточно сложным интеллектуальным агентом, который обрабатывает медицинские диагнозы. В модели «классной доски» эти решатели задач называются источниками знаний. Чтобы решить задачу с использованием «классной доски», необходимо наличие двух или больше источников знаний, которые обычно обладают различной специализацией. Модель «классной доски» более подходит для задач, разделяемых на отдельные подзадачи, которые можно решать независимо (или почти независимо) от других. В базовой конфигурации архитектуры «классной доски» каждый решатель занимается «своей» частью задачи, т.е. он «видит» только часть общей задачи, с которой работает. Если решение одной части задачи зависит от решения другой ее части, то «классная доска» используется для координации действий решателей задач и объединения частных решений. Решатели задач, задействованные в архитектуре «классной доски», не должны быть одинаковыми. Каждый из них может быть реализован по своему. Например, одни решатели задач могут быть реализованы с использованием объектно-ориентированных технологий, а другие — как функции. Более того, решатели задач могут использовать совершенно различные парадигмы решения. Например, решатель А для решения своей подзадачи может применять метод обратного построения цепочки (т.е. ведения рассуждений от целевой гипотезы к исходным посылкам), а решатель В — метод от противного. При этом также необязательно, чтобы решатели задач были реализованы с помощью одного и того же языка программирования.

Модель «классной доски» не определяет никакой конкретной структуры ни для самой «классной доски», ни для источников знаний. Как правило, структура «классной доски» зависит от конкретной задачи.1 [22] Реализация источников знаний также зависит от специфики решаемой задачи. «Классная доска» — это концептуальная модель, описывающая отношения без представления структуры самой «классной доски» и источников знаний. Модель «классной доски» не диктует количество используемых источников знаний или их назначение. «Классная доска» может быть единственным глобальным или распределенным объектом, компоненты которого расположены на нескольких компьютерах. Системы «классной доски» могут состоять из нескольких «классных досок», и каждая из них «занимается» решением определенной части исходной задачи. Это делает модель «классной доски» чрезвычайно гибкой. Модель «классной доски» поддерживает параллельное и распределенное программирование. Во-первых, источники знаний, работая над решением части общей задачи, могут выполняться одновременно. Во-вторых, источники знаний могут быть реализованы в различных потоках или отдельных процессах одного или нескольких компьютеров.

«Классная доска» может быть разделена на несколько отдельных частей, позволяющих параллельный доступ со стороны нескольких источников знаний. «Классная доска» легко поддерживает такие архитектурные варианты, как CREW (concurrent read, exclusive write — параллельное чтение и монопольнал запись), EREW (exclusive read, exclusive write — монопольное чтение и монопольная запись) и MIMD (multiple-instruction, multiple-data — множество потоков данных и множество потоков команд). Мы реализуем «классную доску» как глобальный объект или коллекцию объектов, а источники знаний — как отдельные потоки. Поскольку потоки разделяют одно и то же адресное пространство, к «классной доске», реализованной как глобальный объект или семейство объектов, будут получать доступ все потоковые источники знаний. Если источники знаний реализовать как отдельные процессы, выполняющиеся на одном или нескольких компьютерах, то «классную доску» имеет смысл реализовать как CORBA-объект или как коллекцию CORBA-объектов. Вспомните, что CORBA-объекты можно использовать для поддержки как параллельной, так и распределенной модели вычислений. Здесь мы используем технологию CORBA для поддержки «классной доски» как разновидность распределенной памяти, совместно используемой задачами, выполняющимися в различных адресных пространствах. Эти задачи могут быть PVM-типа (Рагаllеl Virtual Machine — параллельная виртуальная машина), задачами, порождаемыми традиционными fork-exec-вызовами функций, или задачами, порождаемыми библиотечными функциями posix_spawn (). Две конфигурации памяти для реализации технологии «классной доски» показаны на рис. 13.1.

В обоих случаях (см. рис. 13.1) все источники знаний имеют доступ к «классной доске». Источники знаний, размещенные в различных адресных пространствах, должны иметь сетевую связь с «классной доской», реализованной как один или несколько CORBA-объектов. Если источники зна н ий реализова н ы как PVM-задачи. то их связь с «классной доской» можно построить на основе передачи сооб щ ений. Такая конфигурация обеспечивает чрезвычайно гибкую модель решения задач.

Рис.13.1. Две конфигурации памяти для реализации технологии «классной доски» (ИЗ — источник знаний)

Методы структурирования «классной доски»

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

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

Рис. 13.2. Логическая схема базовой архитектуры «классной доски»

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

Анатомия источника знаний

Источники знаний представляются как объекты, процедуры, множества правил, логические утверждения, а в некоторых случалх и целые программы. Источники знаний включают часть условий и часть действий. Если «классная доска» содержит информацию, которая удовлетворяет части условий некоторого источника знаний, то его часть действий активизируется. Инглемор (Englemore) и Морган (Morgan) в своей работе [14] четко описывают обязанности источника знаний.

Каждый источник знаний отвечает за знание условий, при которых он может внести свой вклад в решение. Каждый источник знаний имеет предусловия, т.е. условия, которые должны быть записаны на «классной доске» и существовать до того, как будет активизировано тело источника знаний. Источник знаний можно рассматривать как большое правило. Главное, чем отличается правило от источника знаний, состоит в степени детализации знаний. Часть условий этого большого правила называется предусловием источника знаний, а часть действий — его телом.

Здесь Инглемор и Морган не определяют ни единой детали части условий или части действий источника знаний. Они представляют собой логические конструкции. Часть условий может иметь форму простого значения булевого флага на «классной доске» или сложной последовательности событий, поступающих в очередь событий в пределах определенного периода времени. Аналогично часть действий источника знаний может быть выражена простой инструкцией, выполняющей операцию присваивания переменной некоторого выражения, или механизмом прямого построения цепочки в экспертной системе. Это описание широты диапазона еще раз подчеркивает гибкость модели «классной доски». Для наших целей вполне достаточно конструкции С++-класса и понятия объекта. Каждый источник знаний должен быть объектом. Часть действий источника знаний должна быть реализована в виде методов объекта, а часть условий — в виде его членов данных. Если объект находится в определенном состоянии, то его часть действий должна быть активизирована. Проще говоря, мы реализуем источники знаний в виде потоков или процессов. Следовательно, для каждого потока и для каждого процесса должен существовать только один источник знаний. Применяя к «классной доске» PVM-механизм, источник знаний будет эквивалентом PVM-задачи. Логическая схема источника знаний показана на рис. 13.3.

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

Рис. 13.3. Логическая схема источника знаний

Стратегии управления для «классной доски»

В реализации модели «классной доски» прелусмотрено несколько уровней управления, обеспечивающих возможность параллельного функционирования источников знаний. На самом нижнем уровне их схемы синхронизации должны защищать целостность «классной доски». «Классная доска» является критическим разделом, поскольку она представляет собой совместно используемый модифицируемый ресурс. В параллельной среде доступ со стороны источников знаний для чтения и записи должен быть скоординирован и синхронизирован. Координация и синхронизация может включать блокировку файлов, семафоры, мьютексы и т.д. Этот уровень управления не включается непосредственно в решение, над которым работают источники знаний. Его можно назвать вспомогательным уровнем управления, и он не должен зависеть от специфики задачи, решаемой с помощью «классной доски». В нашем архитектурном подходе этот уровень управления реализуется интерфейсными классами (например, классами мьютекса и семафора, использованными в главе 11). Вспомните, что действия, инкапсулированные в этих классах, не зависят от приложения, в котором они используются. Для параллельных реализаций «классной доски» на этом уровне выбирается один (или больше) из четырех типов параллельного доступа, которыми должны обладать алгоритмы или эвристические правила источников знаний для физической реализации «классной доски». Другими словами, пользователи «классной доски» могут использовать EREW-, CREW-, ERCW- или CRCW-доступ. Именно характер доступа определяет, как будут использованы примитивы синхронизации. Описание упомянутых здесь типов доступа приведено в табл. 13.1.

Таблица 13.1. Четыре типа параллельного доступа, используемых в модели «классной доски»

EREW  Exclusive Read Exclusive Write (монопольное чтение и монопольная запись)

CREW  Concurrent Read Exclusive Write (параллельное чтение и монопольная запись)

ERCW  Exclusive Read Concurrent Write (монопольное чтение и параллельная запись)

CRCW  Concurrent Read Concurrent Write (параллельное чтение и параллельная запись)

При разделении «классной доски» на части будет определено, какие из типов параллельности (см. табл. 13.1) подходят больше всего. Самый гибкий тип (CRCW) доступа может быть достигнут в зависимости от структуры «классной доски». Например, если используется 16 источников знаний, и каждый из них получает доступ к собственному сегменту «классной доски», то такие источники знаний могут параллельно считывать данные с «классной доски» и записывать их туда, не испытывал проблем «гонки» данных.

Следующий уровень управления включает выбор источников знаний. При этом определяется, какие из них следует включить в поиск решения и какие аспекты задачи им поручить. На этом уровне управления принимается решение перенести центр (фокус) внимания на ту или иную область задачи, что и определяет выбор соответствующих источников знаний. При решении задач любого типа всегда ставятся сле-лующие вопросы: «с чего начать?» и «что нужно для этого знать?». Уровень центра внимания отвечает за начальные условия задачи, а также определяет, какие источники знаний необходимо использовать и в какой момент они должны «вступить в игру». «Классной доске» должно быть известно, какими источниками знаний она может располагать, и обычно источники знаний принимают сообщения или параметры, которые предписывают, как им действовать или в какой области пространства решений следует начинать поиск. Для параллельных реализаций этот уровень управления определяет базовую модель параллелизма (распределение решателей задачи). Обычно для «классной доски» используется модель MPMD (Multiple Programs Multiple Data — множество программ и множество потоков данных), известнал также как MIMD (multiple-instruction, multiple-data — множество потоков команд и множество потоков данных), поскольку каждый источник знаний (решатель задачи) имеет собственную область специализации. Однако сама природа задачи иногда может дать право на использование такой популярной модели, как SPMD (Single Program Multiple Data —одна програ мм а, неско л ько потоков дан н ых). В это м с л учае урове н ь управ л е н ия породит N одинаковых источников знаний, но передаст им различные параметры.

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

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

Рис. 13.4. Конфигурации управления и их уровни в архитектуре «классной доски»

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

Вспомните, что CORBA-объект (см. главу 8) является независимым от платформы распределенным объектом. К CORBA -объектам могут получать доступ процессы, выполняющиеся на одном или на разных компьютерах, подключенных к сети. Это делает CORBA-объекты кандидатами для использования в PVM-средах, когда программа делится на ряд процессов, которые могут (или не могут) выполняться на одном и том же компьютере. Обычно PVM-среда используется для передачи сообщений при вторичной роли общей памяти (если она вообще существует). Введение понятия разделяемого и доступного по сети объекта существенно усиливает вычислительные мощности PVM-среды. Следует иметь в виду, что с помощью CORBA-объектов можно смоделировать все, что позволяют смоделировать не распределенные объекты. Это означает, что PVM-задачи, которые имеют совместный доступ к CORBA-объектам, могут получать доступ к контейнерным объектам, объектам оболочки, шаблонов, доменов и другим видам вспомогательных объектов. В данном случае мы хотели бы, чтобы PVM-задачи имели доступ к объектам «классной доски». Поэтому модель передачи сообщений мы дополняем совместным доступом к сложным объектам. Помимо PVM-задач, получающих доступ к распределенным CORBA-объектам, к ним также могут обращаться задачи, порожденные функциями posix_spawn() или fork-exec. Эти задачи выполняются в отдельных адресных пространствах одного и того же компьютера, но могут, тем не менее, связываться с CORBA-объектами, которые расположены либо на том же, либо на другом компьютере. Поэтому, несмотря на то что все задачи, созданные с помощью функций posix_spawn () или fork-exec, должны размещаться на одном компьютере, CORBA-объекты могут располагаться на любом компьютере.

Пример использования CORBA-объекта «классной доски»

Чтобы продемонстрировать наше представление о CORBA-ориентированной «классной доске», рассмотрим ее реализацию, предложенную разработчиками из компании Ctest Laboratories. И хотя полное описание этого варианта выходит за рамки нашей книги, мы все же остановимся на самых важных аспектах «классной доски» и источников знаний, имеющих отношение к нашему архитектурному подхолу к параллельному программированию. «Классная доска» реализует услуги программно-ориентированного консультанта по составлению расписания учебных курсов. «Классная доска» решает задачи планирования учебных курсов для студента типичного колледжа. Студенты часто сталкиваются с проблемой «неудобного» расписания занятий. Во время регистрации курсов всегда существует конкуренция за места в аудиториях. В какой-то момент важные для студента курсы попросту «закрываются». Ведь не зря существует печально известное правило, соответствующее дисциплине обслуживания очереди: «первым пришел — первым обслужен». Поэтому во время регистрации, когда десятки тысяч студентов пытаются записаться на ограниченное количество курсов, важным фактором выступает своевременность. Студент желает пройти курсы, которые дают право на получение диплома. В идеале эти курсы должны быть разнесены во времени. Кроме того, студент хотел бы поддерживать определенную учебную нагрузку и иметь свободное время для домашних и факультативных занятий.

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

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

• консультант по общеобразовательным курсам;

• консультант по основным курсам;

• консультант по факультативным курсам;

• консультант по непрофилирующим курсам.

Итак, рассмотрим фрагмент CORBA-интерфейса «классной доски».

// Листинг 13.1. CORBA-объявления, необходимые для нашего // класса «классной доски»

typedef sequence<long> courses;

interface black_board{

//. . .

void suggestionsForMajor(in courses Major);

void suggestionsForMinor(in courses Minor);

void suggestionsForGeneral(in courses General);

void suggestionsForElectives(in courses Electives);

courses currentDegreePlan();

courses suggestedSchedule();

//. . .

};

Главная цель интерфейса black_board — обеспечить доступ для чтения и записи со стороны источников знаний. В данном случае при разделении «классной доски» необходимо предусмотреть сегменты для каждого источника знаний. [23] Это позволяет источникам знаний получать доступ к «классной доске» посредством CRCW-стратегии. Другими словами, несколько типов источников знаний могут получить доступ к «классной доске» одновременно, но источники знаний одинакового типа должны быть ограничены применением CREW-стратегии. Любой метод или функция-член, с помощью которого источники знаний будут получать доступ к»классной доске», должен быть определен в интерфейсном классе black_board. Класс courses объявляется с использованием типа CORBA, и поэтому его можно применять в качестве параметра и значений, возвращаемых методами при взаимодействии между источниками знаний и «классной доской». Поэтому эти объявления класса black_board

courses Minor; courses Major;

будут использованы для представления информации, которая либо записывается на «классную доску», либо считывается с нее. Тип courses — это синоним для CORBA-типа sequence<long>, полученный в результате использования typedef-объявления. Тип sequence<long> в CORBA представляет собой вектор (массив) переменной длины. Это означает, что переменные типа courses используются для хранения массива элементов типа long. Каждый long-элемент предназначен для хранения кода курса. Каждый код курса представляет курс обучения, предлагаемый в колледже. Поскольку С++ не имеет типа sequence, то объявление sequence<long> преобразуется в С++-класс. Этот класс имеет такое же имя, как sequence<long> typedef: courses. Процесс преобразования из CORBA-типов в типы С++ происходит во время IDL-компиляции при построении CORBA-приложения. IDL-компилятор должен перевести объявление sequence<long> в С++-код, С++-класс courses должен автоматически включать перечисленные ниже функции.

allocbuf() freebuf() get_buffer() length() operator[] release() replace() maximum ()

Источники знаний будут взаимодействовать с «классной доской» с помощью этих методов. Объявление sequence<long> «невидимо» для источников знаний; они «видят» только класс courses. Поскольку CORBA поддерживает такие типы данных, как структуры (struct), классы, массивы и последовательности, источники знаний могут обмениваться с «классной доской» высокоорганизованными объектами. Это позволяет программисту поддерживать объектно-ориентированное представление при обмене данными с «классной доской». Поддержка объектно-ориентированного представления (где это необходимо) является важным фактором понижения уровня сложности параллельного программирования. Способность просто считывать с «классной доски» и записывать на нее сложные объекты или даже иерархии объектов упрощает программирование в параллельных приложениях. Нет необходимости выполнять преобразование из примитивных типов данных в сложные объекты: можно совершать обмен сложными объектами напрямую.

Реализация интерфейсного класса black_board

Обратите внимание на то, что в интерфейсном классе (см. листинг 13.1) нет объявлений переменных. Вспомните, что интерфейсный класс в CORBA-реализации ограничивается только объявлением методов. В интерфейсном классе не существует компонентов, предназначенных для хранения информации. CORBA-классы должны тесно контактировать с С++-реализациями до конца работы приложения. Реальные реализации методов и необходимых переменных вносятся в производный класс (выведенный из этого интерфейсного класса). Производный класс, выведенный из интерфейсного класса black_board, представлен в листинге 13.2.

// Листинг 13.2. Фрагмент класса реализации для

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

#include «black_board.h»

#include <set.h>

class blackboard : virtual public POA_black_board{

protected:

//. . .

set<long> SuggestionForMajor;

set<long> SuggestionForMinor;

set<long> SuggestionForGeneral;

set<long> SuggestionForElective;

courses Schedule; courses DegreePlan;

public:

blackboard(void); ~blackboard(void);

void suggestionsForMajor(const courses &X);

void suggestionsForMinor(const courses &X);

void suggestionsForGeneral(const courses &X);

void suggestionsForElectives(const courses &X);

courses *currentDegreePlan(void);

courses *suggestedSchedule(void);

//. . .

} ;

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

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

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

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

class POA_black_board : virtual public PortableServer::StaticImplementation

{

public:

virtual -POA_black_board (); black_board_ptr _this ();

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

(const PortableServer::ObjectId &, PortableServer::POA_ptr);

virtual void * _narrow_helper (const char *); static POA_black_board * _narrow (

PortableServer::Servant); virtual CORBA::Object_ptr _make_stub (PortableServer::

POA_ptr,

CORBA::Object_ptr);

//.. .

virtual void suggestionsForMajor (const courses& Major)

= 0;

virtual void suggestionsForMinor (const courses& Minor)

= 0;

virtual void suggestionsForGeneral (

const courses& General) = 0;

virtual void suggestionsForElectives (

const courses& Electives) = 0;

virtual courses* currentDegreePlan() = 0;

virtual courses* suggestedSchedule() = 0;

//. . . protected:

POA_black_board () {}; private:

POA_black_board (const POA_black_board &); void operator= (const POA_black_board &);

};

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

virtual courses* suggestedSchedule() = 0;

Это означает, что данный класс нельзя использовать напря м ую. Из него необходи м о вывести производный класс, в которо м будут определены реальные функции-члены для всех объявлений чисто виртуальных функций. Класс POA_black_board, представленный в листинге 13.2, содержит требуе м ые определения для всех чисто виртуальных функций-членов. Что касается нашего класса «классной доски*', то для реализации действий са м ой «доски» и источников знаний используются С ++-м етоды. Однако источники знаний реализованы частично в языке С++ и частично в языке логического про г ра мм ирования Prolog. [24] Но поскольку С++ под д ерживает мультиязыковую и мультипарадигматическую разработку, к средствам С++ можно вполне добавить достоинства языка Prolog. В С++ мы можем либо породить Prolog-задачи (с помощью posix_spawn() - или fork-exec-функций), либо получить доступ к среде Prolog через ее интерфейс с незнакомыми языками программирования, который позволяет Prolog-среде общаться непосредственно с С++ и наоборот. Независимо от того, на каком языке создана реализация источников знаний — С++ или Prolog, объект «классной доски» должен взаимодействовать только с С++-методами.

Порождение источников знаний в конструкторе «классной доски»

«Классная доска» реализуется как распределенный объект, использующий CORBA-протокол. В данном случае одной из основных целей «классной доски» является порождение источников знаний. Это важный момент, поскольку «классная доска» должна иметь доступ к идентификационным номерам задач. Начальное состояние «классной доски» (оно устанавливается в конструкторе) включает информацию о студенте, его академической характеристике, текущем семестре, требованиях для получения диплома и т.д. С помощью «классной доски», исходя из начального состояния, определяется, какие источники знаний следует запустить в работу. Иначе говоря, оценив начальную задачу и исходное состояние системы, «классная доска» составляет список запускаемых на выполнение источников знаний. Каждый источник знаний имеет соответствующий двоичный файл, а для хранения имен этих файлов «классная доска» использует контейнер Solvers. Позже, при функционировании конструктора, с по м ощью функционального объекта (или объекта-функции) и алгоритма for_each() порождаются источники знаний. Вспомните, что любой класс, в котором определена операторная функция operator(), м ож н о испо л ьзовать как функциональный объект. Объекты-функции, как прави л о при м еняют сов м естно со стандартны м и алгорит м а м и в м есто функций и л и в допо л нение к ни м. Обычно везде, где м ожно использовать обычную функцию, ее м ожно за м енить объекто м -функцией. Чтобы определить собственный функциональный объект, необходи м о определить операторный м етод operator (), придав е м у соответствующий с м ысл, указав список пара м етров и тип возвращае м ого и м значения. Наша CORBA-реализация «классной доски» м ожет под д ерживать источники знаний, реализованные с по м ощью PVM-задач, традиционных UNDC/Linux-задач или от д ельных потоков, использующих библиотеки POSIX thread. По типу задач, порождае м ых в конструкторе, м ожно определить, с каки м и и м енно задача м и будет работать «классная доска»: с POSIX-потока м и, традиционны м и UNIX/Linux-процесса м и или PVM-задача м и.

Порождение источников знаний с помощью PVM-задач

Конструктор «классной доски» содержит следующий вызов алгоритма, for_each(Solve.begin(),Solve.end(), Task);

Алгоритм for_each () применяет операторный метод объекта функции (созданного для класса задачи) к каждому элементу контейнера Solve. Этот метод используется для порождения источников знаний в соответствии с моделью MIMD, при реализации которой все источники знаний имеют различную специализацию и работают с различными наборами данных. Объявление этого класса задач приведено в листинге 13.4.

// Листинг 13.4. Объявление класса задачи

class task{

int Tid[4];

int N;

//. . .

public:

//. . .

task(void) { N = 0; } void operator()(string X);

};

void task::operator()(string X) {

int cc; pvm_mytid();

cc = pvm_spawn(const_cast<char *>(X.data()),NULL,0,"",l,&Tid[N]);

N++;

}

blackboard::blackboard(void) {

task Task;

vector<string> Solve;

//.. .

// Determine which KS to invoke

//. . .

Solve.push_back(KS1);

Solve.push_back(KS2);

Solve.push_back(KS3);

Solve.push_back(KS4);

for_each(Solve.begin(), Solve.end(), Task);

}

Этот класс task инкапсулирует порожденный процесс. Он содержит идентификационный но м ер задачи (поскольку у нас используется PVM-задача). В случае при м енения стандартных UNDC/Linux-процессов или Pthread-потоков, он должен содержать идентификационный но м ер процесса или потока. Этот класс действует как интерфейс между создаваемым процессом или потоком и «классной доской». «Классная доска» здесь является основным компонентом управления. Она может управлять PVM-задачами с помощью их идентификационных номеров. Кроме того, «классная доска» может использовать групповые PVM-операции для синхронизации PVM-задач с использованием барьеров, организации PVM-задач в логические группы, которые должны отрабатывать определенные аспекты решаемой задачи, и сигнализации членов группы с помощью соответствующих тегов сообщений. Групповые PVM-операции перечислены и описаны в табл. 13.2.

Особый интерес для нашей «классной доски» представляют операции pvm_barrier() и pvm_joingroup(), поскольку существуют ситуации, в которых «классная доска» не запускает новые источники знаний до тех пор, пока определенная группа источников знаний не завершит свою работу. Для блокирования вызывающего процесса до нужного момента (до окончания обработки данных соответствующими источниками знаний) можно использовать операцию pvm_barrier (). Например, «классная доска» в качестве консультанта по выбору курсов обучения не будет активизировать источник знаний, отвечающий за составление расписания, до тех пор, пока не представят свои предложения источники знаний, которые специализируются на основных, общеобразовательных, второстепенных и факультативных курсах. Поэтому «классная доска» будет использовать операцию pvm_barrier () для ожидания завершения работы этой группы PVM-задач. На рис. 13.5 представлена UML-диаграмма видов деятельности, которая позволяет понять, как синхронизируются источники знаний и «классная доска».

Барьер синхронизации здесь реализуется с помощью операций pvm_barrier () и pvm_joingroup (). Реализация операторной функции для объекта задачи приве д ена в л истин г е 13.5.

Таблица 13.2. Групповые PVM-операции

int pvm_joingroup (char *groupname); Вносит вызывающий процесс в группу groupname, а затем возвращает int-значение, которое представляет собой номер процесса в этой группе

int pvm_lvgroup (char *groupname); Удаляет вызывающий процесс из группы groupname

int pvm_gsive (char *groupname); Возвращает int-значение, которое представляет собой количество членов в группе groupname

int pvm_gettid (char *groupname, int inum); Возвращает int-значение, равное идентификационному номеру задачи, выполняемой процессом, который идентифицируется именем группы groupname и номером экземпляра inum

int pvm_getinst (char *groupname, int taskid); Возвращает int-значение, которое представляет собой номер экземпляра, связанный с именем группы groupname и процессом, выполняющим задачу с идентификационным номером taskid

int pvm_barrier (char *groupname, int count); Блокирует вызывающий процесс до тех пор, пока count членов в группе groupname не вызовут эту функцию

int pvm_bcast (char *groupname, int messageid); Передает всем членам группы groupname сообщение, хранимое в активном буфере отправки, связанном с номером messageid

int pvm_reduce (void *operation, void *buffer, int count, int datatype, int messageid, char *groupname, int root); Выполняет глобальную операцию operation во всех процессах группы groupname

Рис.13.5. UML-диаграмма видов деятельности, отображающая синхронизацию «классной доски» и источников знаний

// Листинг 13.5. Определение функции operator() // в классе task

void task::operator()(string X) {

int cc; pvm_mytid();

cc = pvm_spawn(const_cast<char *>(X.data()),NULL,0,"",l, &Tid[N]);

N++;

}

Функция-оператор operator () используется для порождения PVM-задач. Имя задачи содержится в элементе X. data (). При обращении к функции pvm_spawn () (см. листинг 13.5) создается одна задача, а ее идентификационный номер сохраняется в элементе Tid[N] . (Подробнее о функции pvm_spawn () и вызове PVM-задач см. гла-вуб.) Класс task используется для создания функциональных объектов (объектов-функций). При выполнении алгоритма

for_each(Solve.begin(),Solve.end(),Task);

вызывается функция operator (), которая выполняет объект Task. Эта операция заставляет активизироваться источники знаний, содержа щ иеся в контейнере Solve. Алгоритм for_each () гарантирует активизацию всех источников знаний. Если используется м одель SIMD, то в алгоритме for_each () нет никакой необходимости. Вместо него прямо в конструкторе «классной доски» мы используем вызов функции pvm_spawn(). В листинге 13.6 как раз и показано, как при использовании модели SIMD можно запустить множество PVM-задач из конструктора «классной доски».

// Листинг 13.6. Запуск PVM-задач из конструктора

// класса task

void task::operator()(string X) {

int cc; pvm_mytid();

cc = pvm_spawn(const_cast<char *>(X.data()),NULL,0,"",l, &Tid[N]);N++;

}

Связь «классной доски» и источников знаний

Согласно коду, приведенному в листинге 13.6, порождается 20 источников знаний. Сначала все они выполняют одинаковый код. После их порождения «классная доска» должна отправить сообщения с указанием, какую роль они будут играть в процессе решения задачи. При использовании данной конфигурации источники знаний и «классная доска» являются частью PVM-среды. После создания источники знаний будут взаимодействовать с «классной доской» путем соединения с портом, на котором она размещается, или по ее адресу в сети intranet или Internet. Для этого источникам знаний понадобится объектная ссылка на «классную доску». Эти ссылки можно «зашить» в код источников знаний, или они могут прочитать их из файла конфигурации либо получить из службы имен. Имея ссылку, источник знаний взаимодействует с ORB-брокером (Object Request Broker — брокер объектных запросов), чтобы найти удаленный объект, содержащий реальные данные (знания) и активизировать его. Для нашего примера мы назначаем «классной доске» конкретный порт и запускаем CORBA-объект «классной доски» с помощью следующей ко м анды,

blackboard -ORBIIOPAddr inet:porthos:12458

По этой команде запускается наша программа «классной доски» с подключением к порту 12458 хоста porthos. Запуск CORBA-объекта зависит от используемой CORBA-реализации. В данном случае мы используем «открытую» CORBA-реализацию Mico [25] При выполнении программы blackboard реализуется экземпляр «классной доски», который в свою очередь порождает источники знаний. В созданных источниках знаний жестко закодирован номер порта, по которому они будут связываться с «классной доской». Фрагмент кода реализации источника знаний, который связывается с CORBA - ориентированным объектом «классной доски», представлен в листинге 13.7.

// Листинг 13.7. Код источника знаний, который связывается

// с CORBA-ориентированной «классной доской»

1 #include «pvm3.h»

2 using namespace std;

3 #include <iostream>

4 #include <fstream>

5 #include <string.h>

6 #include <strstream>

7 #include «black_board_impl.h» 8

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

10 {

11 CORBA::ORB_var Orb = CORBA::ORB_init(argc, argv,«mico-local-orb»);

12 CORBA::Object_yar Obj =Orb->bind(«IDL:black_board:1.0»,«inet:por thos:12 4 5 8»);

13 courses Courses;

14 //...

15 //...

16 black_board_var BlackBoard = black_board::_narrow(Obj);

17

18 int Pid;

19 //...

20 //... 21

22 cout « «Источник знаний создан.» « endl;

23 Courses.length(2);

24 Courses[0] = 255551;

25 Courses[l] = 253212;

26 string FileName;

27 strstream Buffer;

28 Pid = pvm_mytid();

29 Buffer « «Результат.» « Pid « ends;

30 Buffer » FileName;

31 ofstream Fout(FileName.data());

32 BlackBoard->suggestionsForMajor(Courses);

33 Fout.close();

34 pvm_exit();

35 return(0);

36 } 37

В строке 11 (см. листинг13.7) инициализируется ORB брокер . При выполнении строки 12 осу щ ествляется связывание имени объекта black_board с портом 12458 и возвра щ ается ссылка на CORBA-объект в переменной Obj. Строку 16 можно расценивать как разновидность операции приведения типа, чтобы Переменная BlackBoard ссылалась на объект «правильного размера». После того как источник знаний реализовал объект BlackBoard, он может вызывать любой метод, объявленный в интерфейсе black_board, код которого приведен в листинге 13.1. Обратите внимание на создание в строке 13 объекта Courses. Вспомните, что тип courses изначально был определен как CORBA-тип sequence. Здесь источник знаний использует класс courses, созданный во время IDL-компиляции. Добавление элементов в этот класс можно представить как добавление элементов в любой массив. При выполнении строк 24 и 25 в объект Courses добавляются два элемента, а в строке 32 содержится вызов метода, которому в качестве параметра передается объект Courses: BlackBoard->suggestionsForMaj or(Courses)

При выполнении этого вызова информация о курсах обучения записывается на «классную доску». Аналогично следующие методы

courses currentDegreePlan(); courses suggestedSchedule();

можно использовать для считывания информации с «классной доски». Поэтому для об щ ения с «классной доской» источнику знаний достаточно иметь ссылку на объект Black_board. Объект Black_board может располагаться в любом м есте сети intranet или Internet. Найти реальное м естоположение удаленного объекта — забота исключительно ORB-боркера. (Процесс отыскания и активизации CORBA-объектов расс м атривается в главе8.) Поскольку объект Black_board и м еет идентификационные но м ера PVM-задач, он м ожет управлять эти м и задачами и обмениваться сообщениями (отправлять и получать их) непосредственно с источниками знаний. Аналогично источники знаний могут напрямую взаимодействовать друг с другом, используя традиционный обмен PVM-сообщениями. Важно отметить следующее: после того как окажется, что не существует больше никаких системных PVM-вызовов, деструктор объекта Black_board должен вызвать м етод pvm_exit(), а каждый источник знаний — м етод pvm_exit (). Те м са м ы м из PVM-среды будут удалены ненужные больше объекты, но обработкаданных, не связанная с эти м и объекта м и, м ожет продолжаться.

Активизация источников знаний с помощью POSIX-функции spawn()

Реализация источников знаний в ра м ках PVM-задач особенно полезна в ситуации, если задачи должны выполняться на разных компьютерах. Каждый источник знаний в этом случае может воспользоваться преимуществами любого специализированного ресурса, которым может быть оснащен конкретный компьютер. К таким ресурсам можно отнести быстродействующий процессор, базу данных, специальное периферийное оборудование и наличие нескольких процессоров. PVM-задачи можно также использовать на одном компьютере с несколькими процессорами. Но поскольку взаимодействие с нашей «классной доской» легко реализовать путем подключения к порту, для реализации источников знаний, не мудрствуя лукаво, мы можем также использовать традиционные UNDC/Linux-процессы. Если источники знаний создаются в стандартных UNIX/Linux-процессах, а компьютер содержит несколько процессоров, то источники знаний могут выполняться параллельно на этих процессорах. Но если источников знаний больше, чем процессоров, возникает необходимость в многозадачности. На рис. 13.6 показаны два простых архитектурных варианта, которые можно использовать с CORBA-ориентированной «классной доской» и UNIX/Linux-процессами.

Рис. 13.6. Два архитектурных варианта использования CORBA-ориентированной «классной доски» и UNIX/Linux-процессов

В варианте 1 CORBA-объект и источники знаний размещаются на одном компьютере, и каждый источник знаний имеет собственное адресное пространство. Другими словами, каждый источник знаний порожден с помощью функции posix_spawn() или семейств а функций fork-exec. В варианте 2 CORBA-объект размещается на одном компьютере, а все источники знаний — на другом, но в различных адресных пространствах. В обоих вариантах CORBA-объект действует как разновидность общей памяти для источников знаний, поскольку все они получают доступ к нему и могут обмениваться информацией через «классную доску». При этом важно помнить о существовании основного преимущества CORBA-объекта — он имеет более высокую организацию, чем простой блок памяти. «Классная доска» — это объект, который может состоять из структур данных любого типа, объектов и даже других «классных досок». Такой вид организации не может быть реализован простым использованием базовых функций доступа к общей памяти. Поэтому CORBA-реализация обеспечивает идеальный способ разделения сложных объектов между процессами. В подразделе 13.5.3.1 описано создание PVM-задач, которые реализуют источники знаний. Здесь мы изменяем конструктор, включал в него вызовы функции posix_spawn () (с той же целью можно использовать алгоритм for_each () и функциональный объект задачи для вызова функции posix_spawn()). В варианте 1 (см. рис. 13.6) «классная доска» может порождать источники знаний при реализации конструктора. Но в варианте 2 это невозможно, поскольку «классная доска» расположена на отдельном компьютере. Поэтому в варианте 2 «классной доске» для вызова функции posix_spawn () приходится прибегать к услугам посредника. Посредничество можно организовать разными способами, например, «классная доска» может вызвать другой CORBA-объект, расположенный на одном компьютере с источниками знаний. С той же целью можно использовать удаленный вызов процедуры (Remote Procedure Call — RPC) или MPI- либо PVM-задачу, которая должна вызвать программу, содержащую обращение к функции posix_spawn (). (Описание вызовов функции posix_spawn () приведено в главе 3.) Как можно использовать функцию posix_spawn() для активизации одного из источников знаний, показано в листинге 13.8.

// Листинг 13.8. Использование функции posix_spawn() для

// запуска источников знаний

#include <spawn.h> blackboard::blackboard(void) {

//.. .

pid_t Pid;

posix_spawnattr_t M;

posix_spawn_file_actions_t N;

posix_spawn_attr_init(&M);

posix_spawn_file_actions_init(&N);

char *const argv[] = {«knowledge_source1»,NULL};

posix_spawn(&Pid,«knowledge_source1»,&N,&M,argv,NULL);

//. . .

}

В листинге 13.8 инициализируются атрибуты и действия, необходимые для порождения задач, после чего с помощью функции posix_spawn() создается отдельный процесс, который предназначен для выполнения источника знаний knowledge_source1. После создания этого процесса «классная доска» получает к нему доступ через его идентификационный номер, сохраняемый в параметре Pid. Кроме «классной доски», используемой в качестве средства связи, возможно и стандартное межпроцессное взаимодействие (IPC), если «классная доска» расположена на одном компьютере с источниками знаний. «Классная доска» — самый простой способ взаимодействия между источниками знаний, хотя в конфигурации размещения «классной доски» на отдельном компьютере можно использовать с этой целью сокеты. В этом случае управление, осуществляемое «классной доской» над источниками знаний, будет более жестким и обусловленным в любой момент времени содержимым «классной доски», а не сообщениями, передаваемыми непосредственно источникам знаний. Прямую пересылку сообщений легче реализовать при использовании «классной доски» в сочетании с PVM-задачами. В этом случае источники знаний сами настраивают себя на основе содержимого «классной доски». Но «классная доска» все же имеет определенный «рычаг»управления источниками знаний, поскольку ей «известны» идентификационные номера всех процессов, содержащих источники знаний. Как модель MPMD (MIMD), так и модель SPMD (SIMD), также поддерживаются использованием функции posix_spawn(). В листинге 13.9 представлен класс, который можно использовать в качестве объекта-функции при выполнении алгоритма for_each ().

// Листинг 13.9. Использование класса child_process как

// объекта-функции при запуске источников

// знаний

class child_process{

string Command;

posix_spawnattr_t M;

posix_spawn_file_actions_t N;

pid_t Pid;

//.. .

public:

child_process(void);

void operator()(string X);

void spawn(string X);

};

void child_process::operator()(string X) {

//.. .

posix_spawnattr_init(&M);

posix_spawn_file_actions_init(&N);

Command.append("/tmp/");

Command.append(X);

char *const argv[] = {const_cast<char*>(Command.data()),NULL};

posix_spawn(&Pid,Command.data(),&N,&M,argv,NULL);

Command.erase(Command.begin(), Command.end()); //.. .

}

Мы инкапсулируем атрибуты, необходимые для функции posix_spawn() , в классе child_process. Инкапсуляция всех данных, требуемых для вызова этой функции в классе, упро щ ает ее использование и обеспечивает естественный интерфейс с атрибутами процесса, который создается с ее помощью. Обратите внимание на то, что в классе child_process мы определили функцию operator () (см. листинг 13.9). Это означает, что класс child_process можно использовать в качестве функционального объекта при выполнении алгоритма for__each (). По мере того как «классная доска» решает, какие источники знаний необходимо активизировать для решения задачи, она сохраняет их имена в контейнере Solve. Позже при выполнении конструктора «классной доски» нужные источники знаний активизируются с помощью алгоритма for_each ().

// Конструктор.

//...

child_process Task;

for_each(Solve.begin(), Solve.end(), Task);

При выполнении этого конструктора для каждого элемента контейнера Solve вызывается метод operator (), код которого приведен в листинге 13.9. После активизации источники знаний получают доступ к ссылке на объект «классной доски» и могут приступать к решению свой части задачи. И хотя источники знаний здесь не являются PVM-задачами, они связываются с «классной доской» таким же способом (см. подраздел 13.5.3.2) и так же выполняют свою работу. Дело в том, что межпроцессное взаимодействие между стандартными UNIX/Linux-процессами отличается от межпроцессного взаимодействия, которое возможно с использованием PVM-среды. Кроме того, PVM-задачи могут располагаться на разных компьютерах, в то время как процессы, созданные с помощью функции posix_spawn(), могут существовать только на одном и том же компьютере. Если процессы, созданные функцией posix_spawn() (либо семейством функций fork-exec), необходимо использовать в сочетании с моделью SIMD, то в дополнение к объекту «классной доски» для назначения источникам знаний конкретных областей задачи, которые они должны решать, можно использовать параметры argc и argv. В случае, когда «классная доска» находится на одном компьютере с источниками знаний, и она активизирует источники знаний в своем конструкторе, то формально «классная доска» является для них родителем, а потомки наследуют от родителя переменные среды. Переменные среды «классной доски» можно использовать в качестве еще одного способа передачи информации источникам знаний. Этими переменными среды можно легко управлять, используя следующие функции.

#include <stdlib.h>

//.. .

setenv();

unsetenv();

putenv();

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

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

Выбор CORBA-ориентированной «классной доски» вполне естествен в условиях, когда источники знаний должны быть реализованы в среде intranet или Internet, или когда в целях соблюдения модульного принципа организации, инкапсуляции и так далее каждый источник знаний реализуется в отдельном процессе. Однако в распределении «классной доски» необходимость возникает не всегда. Если источники знаний можно реализовать в рамках одного процесса или на одном компьютере, то лучше всего в этом случае организовать несколько потоков, поскольку при таком варианте быстродействие выше, расходы системных ресурсов меньше, а сама работа (настройка) — проще. Взаимодействие между потоками легче организовать, поскольку потоки разделяют одно адресное пространство и могут использовать глобальные переменные. Ведь тогда «классную доску» можно реализовать как глобальный объект, доступный всем потокам в процессе. При реализации источников знаний в виде потоков в рамках одной программы отпадает необходимость в межпроцессном взаимодействии, использовании сокетов или какого-либо другого типа сетевой связи. Кроме того, в этом случае оказывается ненужным дополнительный уровень CORBA-протокола, поскольку можно обойтись разработкой обычных C++-классов. Если многопоточная программа рассчитана на использование одного компьютера с несколькими процессорами, то потоки могут выполняться параллельно на доступных процессорах. В SMP- и МРР-системах потоковая конфигурация «классной доски» весьма привлекательна. В общем случае при использовании потоков достигается самая высокая производительность. Потоки часто называют облегченными процессами, поскольку они не требуют таких же расходов системных ресурсов, как традиционные UNIX/Linux-процессы. В библиотеке POSIX threads (Pthreads) предусмотрено практически все, что нужно для создания источников знаний и управления ими. На рис. 13.7.1-13.7.3 представлены три базовые конфигурации распределения процессов для «классной доски» и источников знаний.

Рис. 13.7. Базовая конфигурация распределения процессов для «классной доски» и источников знаний

Поскольку «классная доска» реализована в многопоточной среде, то для синхронизации доступа к «классной доске» можно использовать Pthread-мьютексы и переменные условий, которые необходимо инкапсулировать в интерфейсных классах, как описано в главе 11. Кроме того, для координации и синхронизации работы, выполняемой источниками знаний, можно использовать функции pthread_cond_signal () и pthread_cond_broadcast (). Поскольку «классная доска» сама создает потоки, ей будет нетрудно получить доступ к идентификационным номерам всех источников знаний. Это означает, что «классная доска» может при необходимости аннулировать поток, используя функцию pthread_cancel (). Кроме того, «классная доска» способна синхронизировать выполнение источников знаний с помощью функции pthread_join(). Помимо уже перечисленных достоинств многопоточной реализации (высокое быстродействие и простота использования потоков и глобального объекта «классной доски»), существует также проблема обработки ошибок и исключительных ситуаций.

В общем случае эта проблема решается проще в рамках одного процесса и одного компьютера, чем при использовании нескольких процессов и нескольких компьютеров. На рис. 13.8 показаны уровни сложности, связанные с обработкой ошибок и исключительных ситуаций при использовании различных конфигураций.

Рис. 13.8. Уровни сложности при обработке ошибок и исключений

Если источники знаний реализованы в отдельных потоках одного и того же процесса, то обработка возможных ошибок или исключительных ситуаций в этом случае относится к уровню сложности 2. Эту степень сложности необходимо учитывать еще на этапах проектирования и разработки программы, особенно в случае, если она требует параллельного программирования. Простейшее архитектурное решение, использующее модель «классной доски», состоит в реализации «классной доски» в виде глобального объекта, а источников знаний — в виде потоков. Рассмотрим фрагмент объявления класса blackboard.

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

// разработанного для многопоточной среды

class blackboard{ protected: //.. .

set<long> SuggestionForMajor;

set<long> SuggestionForMinor;

set<long> SuggestionForGeneral;

set<long> SuggestionForElective;

set<long> Schedule;

set<long> DegreePlan;

mutex Mutex[10];

//.. .

public:

blackboard(void) ;

~blackboard(void);

void suggestionsForMajor(set<long> &X);

void suggestionsForMinor(set<long> &X);

void suggestionsForGeneral(set<long> &X);

void suggestionsForElectives(set<long> &X);

set<long> currentDegreePlan(void);

set<long> suggestedSchedule(void);

//.. .

};

Класс blackboard предназначен для реализации в качестве глобального объекта, к которому смогут получать доступ все потоки в программе. Обратите внимание на то, что класс blackboard в листинге 13.10 включает массив мьютексов. Эти мьютексы используются для защиты критических разделов «классной доски». При реализации источников знаний практически нет необходимости беспокоиться о синхронизации доступа к критическим разделам, поскольку код синхронизации инкапсулирован в классе blackboard.

Активизация источников знаний с помощью потоков

В этом разделе рассматривается реализация источников знаний в отдельных потоках. Потоки создаются здесь при выполнении конструктора класса «классной доски» (blackboard), и каждому потоку назначается конкретный источник знаний. Тем самым реализуется модель MIMD. Фрагмент кода конструктора класса blackboard приведен в листинге 13.11.

// Листинг 13.11. Конструктор класса blackboard,

// используемый для создания потоков,

// содержащих источники знаний

blackboard::blackboard(void) {

pthread_t Tid[4];

//.. .

try{

pthread_create(&Tid[0],NULL,suggestionForMajor, NULL);

pthread_create(&Tid[l],NULL, suggestionForMinor, NULL);

pthread_create(&Tid[2], NULL,suggestionForGeneral, NULL);

pthread_create(&Tid[3],NULL, suggestionForElective, NULL);

pthread_join(Tid[0],NULL);

pthread_join(Tid[l],NULL);

pthread_join(Tid[2],NULL);

pthread_join(Tid[3],NULL);

}

//. . .

}

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

void   *suggestionForMajor(void *X);

void   *suggescionForMinor(void *X);

void   *suggestionForGeneral(void *X);

void   *suggestionForElective(void *X);

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

//...

Combination.generateCombinations(1,9, Courses);

Result = Combination.element(9);

//.. .

Blackboard.suggestionsForMinor(Value);

//.. .

Поскольку некоторые разделы «классной доски» имеют ограниченный доступ для отдельных источников знаний, то к этим разделам можно применить CRCW-стратегию доступа (рис. 13.9).

Тип параллелизма, представленный на рис. 13.9, вполне естествен для систем, реализующих модель «классной доски», поскольку «классная доска» часто делится на разделы, относящиеся к определенным частям задачи или подзадачи. Обычно одной проблемной области соответствует один источник знаний, поэтому параллельный доступ к этим разделам вполне уместен.

Резюме

Рис. 13.9. Четыре источника знаний могут параллельно считывать информацию из соответствующих разделов «классной доски» и записывать ее туда

Модель «классной доски» поддерживает параллелизм, который присутствует как в структуре «классной доски», так и в отношениях между «классной доской» и источниками знаний, а также между самими источниками знаний. Модель «классной доски» — это модель решения некоторой задачи. Общая задача делится на части, соответствующие конкретным областям знаний. Каждой области назначается источник знаний, или решатель задач. Источники знаний обычно отличаются самодостаточностью (автономностью) и не требуют интенсивного общения с другими источниками знаний. Необходимое взаимодействие осуществляется через «классную доску». Следовательно, источники знаний позволяют организовать обработку данных в рамках программы по модульному принципу. Такие своеобразные модули могут работать отдельно и параллельно, не требуя сложной синхронизации. «Классную доску» можно реализовать в виде CORBA-объектов. В этом случае источники знаний могут быть распределены в сетях intranet или Internet. «Классная доска» действует как разновидность общей распределенной па м яти д ля за д ач, выполняе м ых в сре д е PVM-типа. В м о д ель «классной д оски» легко вписываются м о д ели MPMD (MIMD) и SPMD (SIMD). Концепция «классной д оски» побуж д ает разработчика раз д елить работу, которую должна выполнить програ мм а, на области знаний. После проведения деко м позиции работ «классная доска» должна содержать м одели ПО пред м етной области и пространства решений. Эти м одели ПО позволяют проектировщику и разработчику вскрыть параллелиз м, который необходи м о реализовать в програ мм е. После классической м одели распределенного програ мм ирования «клиент-сервер» м одель «классной доски» является одной из м о щ ных м оделей, доступных как для распределенного, так и д л я парал л е л ьного програ мм ирования. Источники знаний, и л и решате л и задач, в м оде л и «классной доски» зачастую реализуются как агенты.

Приложение A

Это приложение представляет собой краткий справочник UML-диаграмм, используемых в этой книге. Универсальный язык моделирования (Unified Modeling Language - UML) предлагает графические обозначения, используемые для проектирования, визуализации, моделирования и документирования артефактов системы программного обеспечения. Этот язык является стандартом «де-факто» для моделирования объектно-ориентированных систем. В нем используются символы и обозначения для представления артефактов системы ПО с различных точек зрения. И хотя в книге используются и другие обозначения, это приложение позволит читателю быстро ознакомиться с основными элементами и символами языка UML, которые могут понадобиться ему при составлении Документации на разрабатываемые системы ПО.

Диаграммы классов и объектов

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

Рис.А.1. Различные способы представления класса или объекта. Для классов можно отобразить атрибуты, операции и их область видимости. При обозначении активных классов или объектов используется более жирная линия

Рис. A.3. Способы представления связанных и несвязанных шаблонов или параметризованных классов

Рис. A.2. Различные способы представления множества классов или объектов. Множество экземпляров можно отобразить графически или с помощью обозначения множественности

Диаграммы взаимодейс т вия

Диаграммы взаимодействия предназначены для отображения взаимодействия между объекта м и. Такие диагра мм ы состоят из м ножества объектов, отношений и сооб щ ений, которы м и об м ениваются объекты. Диагра мм ы взаи м одействия включают диагра мм ы сотрудничества, последовательностей и видов деятельности.

Диаграммы сотрудничества

Диаграммы сотрудничества используются для отображения объектов, работающих вместе с целью выполнения некоторой общей работы. Под сотрудничеством в системе понимается временная кооперация множества объектов. Диаграммы этого типа могут отображать организацию или структуру сотрудничества. Это подразумевает отображение всех объектов данного множества, связей между ними, а также отправляемых и получаемых ими сообщений.

Диаграммы последовательностей

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

Рис. A.5. Способы представления единичного и множественного наследования. Существует два стиля, которые можно использовать при участии нескольких классов в отношении: объединенный и разъединенный. При использовании объединенного стиля несколько классов привязываются к единому символу наследования, который указывает на целевой класс. При использовании разъединенного стиля каждый класс имеет собственный символ наследования

A.2.3. Диаграммы видов деятельности

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

Рис. A.6. Примеры различных отношений, которые можно отобразить на диаграммах классов. Для отображения количества экземпляров, участвующих в отношениях, можно использовать обозначение множественности

Рис.А.7. Диаграмма сотрудничества, отображающая организацию сотрудничества в системе и структурные отношения объектов в этом сотрудничестве

Рис.А.8. Диаграмма последовательностей используется для отображения временного упорядочения сообщений, передаваемых между объектами. Активные объекты размещаются в верхней части диаграммы (по оси x). Сообщения, передаваемые между объектами, располагаются по оси у. На диаграмме можно отображать синхронные и асинхронные сообщения. Временное упорядочение сообщений демонстрируется путем чтения сообщений сверху вниз вдоль оси у

Рис. A.9. Диаграммы видов деятельности отображают действия объектов с точки зрения передачи управления от одного объекта другому. Диаграмма этого типа с помощью полосы синхронизации позволяет отобразить разветвление программы на несколько потоков управления (параллельность) и их слияние. Чтобы было понятно, какой объект выполняет соответствующее действие, здесь используется принцип «плавательных дорожек». Эти «плавательные дорожки» могут пересекаться переходами. «Плавательные дорожки» также могут пересекаться полосами синхронизации, что означает, что несколько потоков управления, распределенные по различным объектам, выполняют действия параллельно

A.3. Диаграммы состояний

Диаграмма состояний используется для отображения последовательности изменения состояния объектов. Состояние — это условие, при котором объект занимает ту или иную позицию на своей «линии жизни». Объект за время своего существования может многократно изменять свое состояние. Объекты переходят в новое состояние, если создаются определенные условия, выполняется некоторое действие или происходит соответствующее событие.

Рис.А.10. Диаграммы состояний отображают состояния объектов и их переходы из одного состояния в другое за время их существования. Диаграмма этого вида содержит начальное и конечное состояние объекта. Состояние может включать несколько стадий (частей). Оно может также быть представлено совокупностью других состояний или даже других диаграмм состояний. Подсостояния, которые существуют параллельно в рамках одного объекта, называются параллельными подсостояниями

A.4. Диаграммы пакетов

Диаграммы пакетов используются для организации элементов системы по группам

Рис.А.11. Диаграммы пакетов могут служить для отображения организации элементов системы. При этом можно использовать стереотипы «система» или «подсистема». Если пакет содержит другие элементы, во вкладке (расположенной слева) можно указать имя пакета

Приложение Б [26]

posix_spawn, posix_spawnp

Имя posix_spawn, posix_spawnp — функции порождения процессов (ADVANCED REALTIME)

Синопсис

SPN #include <spawn.h>

int posix_spawn (

pid_t *restrict pid, const char *restrict path,

const posix_spawn_file_actions_t *file_actions, const posix_spawnattr_t *restrict attrp, char *const argv[restrict], char *const envp[restrict]); int posix_spawnp (

pid_t *restrict pid, const char *restrict file,

const posix_spawn_file_actions_t *file_actions, const posix_spawnattr_t *restrict attrp, char *const argv[restrict], char * const envp[restrict]);

Описание

Функции posix_spawn () и posix_spawnp () предназначены для создания нового (сыновнего) процесса из заданного образа процесса. Новый образ процесса создается на основе обычного выполняе м ого файла, и м енуе м ого файлом образа нового процесса.

Если в качестве результата этого вызова выполняется С-програ мм а, то она должна быть представлена как функция языка С следующи м образо м: int main (int argc, char *argv[]);

Здесь argc— количество аргу м ентов, а argv— м ассив си м вольных указателей на аргу м енты функции. Кро м е того, следующая пере м енная extern char **environ; должна быть инициализирована как указатель на массив символьных указателей на строки описания конфигурации среды.

Аргумент argv представляет собой массив символьных указателей на строки с завершающим нулем. Последний член этого массива (он не учитывается аргу м ентом argc) должен быть нулевым указателе м. Эти строки составляют список аргу м ентов, доступных для образа нового процесса. Значение эле м ента argrv[0] должно указывать на и м я файла, который связан с образо м процесса, запускае м о г о функцией posix_spawn() или posix_spawnp().

Аргу м ент envp представляет собой м ассив си м вольных указателей на строки с завершающим нулем. Эти строки составляют среду для образа нового процесса. Массив среды завершается нулевым указателем.

Количество байтов, допустимых для обобщенного аргумента сыновнего процесса и списков строк описания конфигурации среды, составляет {ARG_MAX}. В систе м ной доку м е н тации конкретной реализации (с м. то м Base Definitions стандарта IEEE Std 1003.1-2001, Chapter 2, Conformance) должно быть указано, включаются ли в это значение такие служебные данные, как си м волы конца строки, указатели или байты выравнивания.

Ар г у м ент path, передавае м ый функции posix_spawn() , содержит путевое и м я, которое идентифицирует файл образа ново г о процесса.

Пара м етр file , передавае м ый функции posix_spawnp (), используется для формирования путевого имени, которое идентифицирует файл образа нового процесса. Если пара м етр file содержит си м вол «косая черта», то пара м етр file следует рассматривать как путевое имя файла образа нового процесса. В противно м случае префикс пути д ля это г о файла должен быть получен путе м поиска в катало г ах, указанных с по м ощью пере м енной среды PATH (с м. то м Base Definitions стандарта IEEE Std 1003.1-2001, Chapter 8, Environment Variables). Если эта Переменная среды не определена, результаты поиска определяются конкретной реализацией.

Если пара м етр file_actions является нулевы м указателе м, то файловые дескрипторы, открытые в вызываю щ е м процессе, останутся открыты м и и в сыновне м, за исключение м тех из них, для которых установлен фла г «закрытия после выполнения» FD_CLOEXEC (с м. описание функции fcntl()). Для оставшихся открыты м и файловых дескрипторов все атрибуты соответствую щ их описаний открытых файлов, включал блокировки файлов (с м. описание функции fcntl ()), останутся без из м енений.

Если пара м етр file_actions не содержит значение NULL, то файловые дескрипторы, открытые в сыновне м процессе, должны соответствовать открытым файловым дескрипторам вызывающего процесса, но с учетом модификации, проведенной в соответствии с содержимым объекта действий, адресуемого параметром file_actions, и флаго м FD_CLOEXEC каждого из оставшихся открыты м и (после выполнения действий над файла м и) файловых дескрипторов. Порядок выполнения действий над файла м и должен быть таки м.

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

2.  Маска сигнала, стандартные действия сигналов, а также идентификационные номера эффективного пользователя и группы для сыновнего процесса должны измениться в соответствии со значениями, заданными в объекте атрибутов, адресуемом параметром actrp.

3. Действия над файлами, заданные объектом действий для порождаемого процесса, должны быть выполнены в порядке их добавления в этот объект.

4.  Любой файловый д ескриптор, у которого установлен флаг FD_CLOEXEC (с м. описание функции fcntl ()), д олжен быть закрыт.

Тип объекта атрибутов posix_spawnattr_t опре д еляется в заголовке <spawn. h>. По м еньшей м ере он д олжен со д ержать атрибуты, опре д еленные ниже.

Если в атрибуте spawn-flags объекта, адресуе м ого пара м етро м attrp, установлен флаг POSIX_SPAWN_SETPGROUP, а атрибут spawn-рдгоиртото же объекта не равен нулю, то группа сыновних процессов д олжна быть за д ана эти м (нену л евы м) атрибуто м объекта.

В качестве специального случал, ес л и в атрибуте spawn-flags объекта, а д ресуемого пара м етро м attrp, установ л ен ф л аг POSIX_SPAWN_SETPGROUP, а атрибут spawn-pgroup того же объекта равен ну л ю, то порож д ае м ый сыновний процесс будет входить в новую группу процессов, идентификатор (ID) которой будет равен значению ID его процесса. Ес л и в атрибуте spawn-flags объекта, адресуе м ого пара м етро м attrp, ф л аг POSIX_SPAWN_SETPGROUP не установ л ен, то новый сыновний процесс наслелует группу ро д ите л ьского процесса.

PS Если в атрибуте spawn-flags объекта, а д ресуе м ого пара м етро м attrp, установлен флаг POSIX_SPAWN_SETSCHEDPARAM, но флаг POSIX_SPAWN_SETSCHEDULER не установлен, то образ нового процесса будет изначально обладать стратегией планирования вызывающего процесса с пара м етра м и планирования, за д анны м и в атрибуте spawn-schedparamoбъeкта, адресуемого пара м етро м attrp.

Если в атрибуте spawn-flags объекта, адресуе м ого пара м етро м attrp, установлен флаг POSIX_SPAWN_SETSCHEDULER (независи м о от установки флага POSIX_SPAWN_SETSCHEDPARAM), то образ нового процесса будет изначально обладать стратегией планирования, заданной атрибуто м spawn-schedpolicy объекта, адресуе м ого пара м етро м attrp, и пара м етра м и планирования, заданны м и в атрибуте spawn-schedparamToro же объекта.

Флаг POSIX_SPAWN_RESETIDS в атрибуте spawn-flags объекта, адресуе м ого пара м етро м attrp, обусловливает значение ID эффективного пользователя сыновнего процесса. Если этот флаг не установлен, сыновний процесс наслелует ID эффективного пользователя родительского процесса. Если этот флаг установлен, ID эффективного пользователя сыновнего процесса должен быть установлен равны м значению ID реального пользователя родительского процесса. В любо м случае, если установлен бит режи м а «set-user-ID» д ля файла образа нового процесса, ID эффективно г о пользователя сыновне г о процесса при м ет значение, равное значению ID владельца этого файла до того, как начнет выполняться образ нового процесса.

Флаг POSIX__SPAWN_RESETIDS в атрибуте spawn-flags объекта, адресуе м ого пара м етро м attrp, также обусловливает значение ГО эффективной группы сыновне г о процесса Если этот фла г не установлен, сыновний процесс наслелует ID эффективной группы родительско г о процесса. Если этот флат установлен, ID эффективной группы сыновнего процесса должен быть установлен равны м значению ID реальной группы родительского процесса. В любо м случае, если установлен бит режи м а «set-group-ID» д л я файла образа нового процесса, ID эффективной группы сыновнего процесса примет значение, равное значению ID группы этого файла до того, как начнет выполняться образ нового процесса.

Если в атрибуте spawn-flags объекта, адресуемого параметром attrp, установлен флаг POSIX_SPAWN_SETSIGMASK, то сыновний процесс изначально будет и м еть м аску сигнала, заданную в атрибуте spawn-sigmask объекта , адресуе м ого пара м етро м attrp .

Если в атрибуте spawn-flags объекта, адресуе м ого пара м етро м attrp, установлен флаг POSIX_SPAWN_SETSIGDEF, то сигналы, заданные в атрибуте spawn-sigdefault того же объекта, будут установлены равны м и их действия м по у м олчанию в сыновне м процессе. Сигналы, установленные равны м и действия м по у м олчанию в родительско м процессе, должны быть установлены равны м и действия м по у м олчанию в сыновне м процессе.

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

За исключение м сигнала SIGCHLD, сигналы, которые д олжны игнорироваться образо м вызываю щ его процесса, д олжны игнорироваться сыновни м процессо м, если не опре д елено иное посредство м флага POSIX_SPAWN_SETSIGDEF, установленного в атрибуте spawn-flags объекта, адресуе м ого пара м етро м attrp, и сигнала SIGCHLD, обозначенного в атрибуте spawn-sigdefault того же объекта.

Если сигнал SIGCHLD установлен как игнорируемый вызывающим процессом, точно не установлено, должен ли сигнал SIGCHLD игнорироваться сыновним процессом или он будет установлен равным действию по умолчанию в сыновнем процессе, если не определено иное посредством флага POSIX_SPAWN_SETSIGDEF, установленного в атрибуте spawn-flags объекта, адресуемого параметром attrp, и сигнала SIGCHLD, обозначенного в атрибуте spawn_sigdefault того же объекта.

Если указатель attrp содержит значение NULL, используются значения по умолчанию.

Все атрибуты процесса, на которые не было оказано влияния со стороны атрибутов, установленных в объекте, адресуемом параметром attrp (как было описано выше), или вследствие манипуляций с файловыми дескрипторами, заданных в параметре file_actions, должны присутствовать в образе нового процесса в таком виде, как будто была вызвана функция fork() для создания сыновнего процесса, а затем член семейства функций exec был вызван сыновним процессом для выполнения образа нового процесса.

THR Запускаются ли обработчики разветвлений при вызове функций posix_spawn () или posix_spawnp (), определяется конкретной реализацией.

Возвращаемые значения

При успешном выполнении функция posix_spawn() (и функция posix_spawnp ()) должна возвратить родительскому процессу идентификационный номер (ID) сыновнего процесса в переменной, адресуемой аргументом pid (если его значение не равно NULL), и нуль в качестве значения, возвращаемого функцией. В противном случае сыновний процесс не создается, значение, сохраненное в переменной, адресуемой аргументом pid (если его значение не равно NULL), не определяется, а в качестве значения, возвращаемого функцией, передается код ошибки, обозначающий ее характер. Если аргумент pid содержит нулевой указатель, значение ID сыновнего процесса инициатору вызова не возвращается.

Ошибки

Вызовы функций posix_spawn() и posix_spawnp() могут оказаться неудачными, если:

[EINVAL] значение, за д анное пара м етро м file_actions или пара м етро м attrp, не д ействительно.

Если ошибка возникла после того, как вызывающий процесс успешно вернулся из функции posix_spawn () или posix_spawnp (), то сыновний процесс может завершиться со стагусом выхода (exit status), равным значению 127.

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

Если в атрибуте spawn-flags объекта, а д ресуе м ого пара м етро м attrp, установлен флаг POSIX_SPAWN_SETPGROUP, а функция posix_spawn() или posix_spawnp() потерпела неу д алу при из м енении группы сыновнего процесса, то возвра щ ае м ое значение ошибки бу д ет соответствовать описанию д ля функции setpgid () (или, если ошибка возникнет после того, как вызываю щ ий процесс успешно вернется, сыновний процесс завершится со статусо м выхо д а, равны м значению 127).

PS   Если в атрибуте spawn-flags объекта, а д ресуе м ого пара м етро м attrp, установлен флаг POSIX_SPAWN_SETSCHEDPARAM, а флаг POSIX_SPAWN_SETSCHEDULER не установлен, то, если неу д ачный исхо д функции posix_spawn() или posix_spawnp() вызван о д ной из причин, которые бы привели к отказу функции sched_setparam(), возвра щ ае м ое значение ошибки бу д ет соответствовать описанию д ля функции sched_setparam() (или, если ошибка возникнет после того, как вызываю щ ий процесс успешно вернется, сыновний процесс завершится со статусо м выхо д а, равны м значению 127).

Если в атрибуте spawn-flags объекта, а д ресуе м ого пара м етро м attrp, установлен флаг POSIX_SPAWN_SETSCHEDULER, и если неу д ачный исхо д функции posix_spawn() или posix_spawnp() вызван о д ной из причин, которые бы привели к отказу функции sched_setscheduler(), возвра щ аемое значение ошибки бу д ет соответствовать описанию для функции sched_setscheduler () (или, если ошибка возникнет после того, как вызываю щ ий процесс успешно вернется, сыновний процесс завершится со статусо м выхода, равны м значению 127). Если аргу м ент file_actions не равен значению NULL и определяет для выполнения любое из действий close, dup2 или орел, и если неудачный исход функции posix_spawn() или posix_spawnp() вызван одной из причин, которые бы привели к отказу функций close(), dup2() или open(), возвра щ ае м ое значение ошибки будет соответствовать описанию для функций close (), dup2 () и open() соответственно (или, если ошибка возникнет после того, как вызываю щ ий процесс успешно вернется, сыновний процесс завершится со статусо м выхода, равны м значению 127). Действие, связанное с открытие м файла, м ожет са м о по себе выразиться в любой из ошибок, описанных для функций close () или dup2 (), по м и м о тех, что описаны для функции open ().

Примеры

Отсутствуют.

Замечания по использованию

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

Логическое обоснование

Функция posix_spawn () и ее «близкая родственница» функция posix_spawnp () были введены для преодоления следующих ощутимых трудностей использования функции fork (): функцию fork () сложно (или невозможно) реализовать без обмена (подкачки) или динамической трансляции адреса.

• Обмен (механизм подкачки в оперативную память недостающей страницы виртуальной памяти, затребованной программой) — в общем случае слишком медленный механизм для среды реального времени.

• Осуществление динамической трансляции адреса возможно не везде, где может использоваться библиотека POSIX .

• Создание процессов с помощью библиотеки POSIX не требует трансляции адресов или иных услуг, связанных с MMU (memory management unit — блок управления памятью).

Таким образом, библиотека POSIX использует примитивы создания процессов и выполнения файлов, которые могут быть эффективно реализованы без трансляции адресов или иных MMU-процедур.

Функция posix_spawn() реализуется как библиотечная программа, но обе функции posix_spawn () и posix_spawnp () задуманы как операции ядра операционной системы. Несмотря на то что они могут представлять эффективную замену для многих пар функций fork() /exec, их цель — обеспечить возможность создания процессов для систем, в которых возникают сложности с применением функции fork (), а не полностью вытеснить функции fork () / exec.

Такая роль функций posix_spawn() и posix_spawnp() оказала влияние на их API-интерфейс. Здесь не было попытки обеспечить полную функциональность пар fork()/exec, при использовании которых между созданием сыновнего процесса и выпол н ение м образа нового процесса разрешаются любые определенные пользователе м операции; ведь Любая попытка достичь такого уровня потребовала бы пара м етрического задания используе м ого языка програ мм ирования. Поэто м у функции posix_spawn () и posix_spawnp () представляют собой базовые операции создания процессов, подобные процедура м Start_Process и Start_Process_Search из пакета POSIX_Process_Primitives в языке программирования Ada, а также другим операциям, предусмотренным во многих операционных системах (но не UNIX), оснащенных POSIX -расширениями.

Функции posix_spawn() и posix_spawnp() обеспечивают управление шестью типами наследования: файловыми дескрипторами, идентификационным номером (ID) группы процессов, ID пользователя и группы, маской сигналов, стратегией планирования, а также управление сигналами (будет ли каждый сигнал, игнорируемый в родительском процессе, игнорироваться и в сыновнем, или же он будет установлен равным действию по умолчанию).

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

Управления маской сигналов и установкой сигналов по умолчанию вполне достаточно для поддержки реализации функции system(). Несмотря на то что поддержка функции system() не является одной из явных целей для функций posix_spawn() и posix_spawnp (), все же эта поддержка составляет не менее 50% от общей «суммы целей».

Намерение состоит в том, что обычное насле д ование файлового д ескриптора через функцию fork (), последующий результат за д анных д ействий над файлами и обычное наследование файлового дескриптора через одну из функций семейства exec должно полностью определять наследование открытых файлов. Реализации не нужно принимать никаких решений относительно набора открытых дескрипторов файлов в начале выполнения образа сыновнего процесса, эти решения уже были приняты инициатором вызова функции и выражены в виде набора открытых д ескрипторов файлов и их флагов FD_CLOEXEC в м о м ент вызова, а также объекта действий над файлами, заданного в этом вызове. Мы убеждены, что в случаях, когда POSIX -примитивы языкa Ada (Start_Process) реализованы в библиотеке, этот метод управления наследованием файловых дескрипторов может быть реализован очень легко.

Мы м оже м и д ентифицировать ря д пробле м, связанных с использование м функций posix_spawn( ) и posix_spawnp (), но на м неизвестно решение с м еньши м количество м пробле м. Мо д ификация сре д ы д ля атрибутов сыновнего процесса, которая не определяется с по м о щ ью аргу м ентов attrp или file_actions, д олжна быть выполнена в ро д ительско м процессе, а поскольку ро д ительский процесс обычно стремится сохранить свой контекст, это более затратно, чем аналогичное поведение, достигаемое с помощью функций fork () /exec. Кроме того, сложно модифицировать на время среду многопоточного процесса, поскольку для безопасного изменения среды все потоки должны быть согласованы. Однако на эти затраты еще можно было бы пойти, применяя вызовы тех функций posix_spawn () и posix_spawnp (), которые используют дополнительные возможности. А поскольку расширенные модификации— это исключение, а не правило, и они особенно непригодны в критическом ко времени выполнения коде, сохранение большинства «рычагов управления» средой вне функций posix_spawn () и posix_spawnp () возлагается на соответствующее проектирование.

Функции posix_spawn() и posix_spawnp () не обладают всей полнотой власти, которая характерна для функций fork () / exec. И такой эффект вполне ожидаем. Функция fork () — чрезвычайно мощная. Мы и не надеялись скопировать все ее возможности в простой и быстрой функции, не предъявляя специальных требований к оборудованию. Важно то, что функции posix_spawn () и posix_spawnp () очень близки к средствам создания процессов во многих операционных системах, отличных от UNIX.

Требования

К реализации функций posix_spawn() и posix_spawnp() предъявляются следующие требования.

• Они должны быть реализованы без использования MMU (memory management unit — блок управления памятью) или какого-то иного специального оборудования.

• Они должны быть совместимы с существующими POSIX -стандартами. Дополнительные требования таковы.

• Они должны быть эффективными.

• Их способность по замещению функции fork () (в обычных условиях) должна составлять не меньше 50%.

• Система, в которой реализованы функции posix_spawn () и posix_spawnp (), но не реализована функция fork (), должна иметь достаточную эффективность, по крайней мере для приложений реального времени.

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

Двухвариантный синтаксис

POSIX-функция exec имеет несколько последовательностей вызовов с приблизительно одинаковой результативностью. Это вызвано практическими реалиями. Поскольку установившаяся практика использования функций posix_spawn() существенно отличается от POSIX-варианта, мы посчитали, что простота важнее полной совместимости. Поэтому мы представили только две модификации для функции posix_spawn ().

Различий в списках параметров между функциями posix_spawn () и posix_spawnp () практически нет; при использовании функции posix_spawnp() второй параметр интерпретируется более сложно, чем при использовании функции posix_spawn ().

Совместимость с POSIX.5 (Ada)

Процедуры Start_Process и Start_Process_Search из пакета привязки языка Ada POSIX_Process_Primitives к POSIX.1 . инкапсулируют действия функций fork() и ехес практически так же, как это делают функции posix_spawn() и posix_spawnp(). Первоначально, придерживаясь цели более простого подхода, разработчики стандарта ограничили возможности функций posix_spawn() и posix_spawnp() подмножеством возможностей, присущих процедурам Start_Process и Start_Process_Search, отказавшись от поддержки конкретных нестандартных средств. Но на основе пожеланий группы приема стандарта усовершенствовать отображение дескрипторов файлов или совсем отказаться от них, а также по рекомендации членов рабочей группы Ada Language Bindings разработчики стандарта решили, что функции posix_spawn() и posix_spawnp() должны быть в достаточной степени эффективными для реализации возможностей процедур Start_Process и Start_Process_Search. Мы исходили из того, что если привязка языка Ada к такому базовому варианту уже была одобрена в качестве стандарта IEEE, то вряд ли не будут одобрены эквивалентные части С-привязки. Среди возможностей, реализованных функциями posix_spawn() и posix_spawnp(), можно насчитать только следующие три пункта, которые не обеспечивались процедурами Start_Process и Start_Process_Search: необязательное задание идентификационного номера группы сыновних процессов, набор сигналов, подлежащих стандартной обработке в сыновнем процессе, а также стратегия планирования (и ее параметры).

Для того чтобы привязку языка Ada в виде процедуры Start_Process можно было реализовать с помощью функции posix_spawn (), функции posix_spawn () пришлось бы явно передавать пустую маску сигналов и среду родительского процесса везде, где инициатор вызова процедуры Start_Process позволял установку этих аргументов по умолчанию, поскольку в функции posix_spawn() такой установки аргументов по умолчанию не предусмотрено. Способность процедуры Start_Process маскировать определенные пользователем сигналы во время ее выполнения является уникальной для привязки языка Ada и должна быть обработана в самой привязке отдельно от вызова функции posix_spawn ().

Группа процессов

Поле наследования группы процессов можно использовать для присоединения сыновнего процесса к су щ ествую щ ей группе процессов. Если атрибуту spawn-pgroup объекта, адресуемого параметром attrp, присвоить нулевое значение, то механизм выполнения функции setpgid() обеспечит присоединение сыновнего процесса к группе нового процесса.

Потоки

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

Функции posix_spawn() и posix_spawnp() м огут оказаться полезны м и не для каждой конфигурации. Ведь для поддержки функционирования множества процессов недостаточно ограничиться только их созданием. В некоторых условиях общие затраты системных ресурсов на поддержку «боеспособности» нескольких процессов могут быть довольно высокими. Существующая практика показывает, что необходимость в поддержке множества процессов для систем с «малым ядром» скорее является исключением, чем правилом, а «правило» как раз образуют потоки. Поэтому для операционных систем с одним процессом рассматриваемые функции не представляют интерес.

Асинхронное уведомление об ошибках

Библиотечная реализация функций posix_spawn () или posix_spawnp () не позволяет выявить все возможные ошибки до создания сыновнего процесса. Стандарт IEEE Std 1003.1-2001 обеспечивает возможность индикации ошибок, возвращаемых из сыновнего процесса, которому не удалось успешно завершить операцию создания, с помощью специального статуса выхода, который можно обнаружить, используя значение статуса, возвращаемое функциями wait () и waitpid ().

Интерфейс stat_val и макрос, используемый для его интерпретации, не совсем подходят для цели возврата API-ошибок, но они являются единственным способом, доступным для библиотечной реализации. Таким образом, реализация может заставить сыновний процесс завершиться со статусом выхода 127 в случае любой ошибки, выявленной во вре м я порождения процесса после успешного завершения функции posix_spawn() или posix_spawnp().

Разработчики стандарта для интерпретации значения stat_val предложили использовать два дополнительных макроса. Первый, WIFSPAWNFAIL, предназначен для выявления статуса, который свидетельствует о завершении сыновнего процесса по причине ошибки, обнаруженной во время выполнения операции posix_spawn() или posix_spawnp (), а не во время реального выполнения образа сыновнего процесса; второй макрос, WSPAWNERRNO, должен выделить значение ошибки, если макрос WIFSPAWNFAIL обнаружит сбой. К сожалению, группа приема стандарта резко возражала против этого дополнения, поскольку оно поставило бы библиотечную реализацию функции posix_spawn () или posix_spawnp () в зависимость от модификации функции waitpid(), способной встраивать специальную информацию в значение stat_val для индикации сбоя при порождении процесса.

Восьми бит статуса выхода сыновнего процесса, доступность которых для ожидающего родительского процесса гарантирована стандартом IEEE Std 1003.1-2001, недостаточно для устранения неоднозначности ошибок порождения процесса, которые может возвратить образ любого процесса. Требуется, чтобы в значении stat_val никакие другие биты статуса выхода не были видимы, поэтому упомянутые выше макросы не поддаются строгой реализации на библиотечном уровне. Резервирование значения статуса выхода 127 для таких ошибок порождения процессов согласуется с использованием этого значения функциями system() и popen() при пропадании сигналов в этих операциях, которые возникают после завершения функции, но перед тем, как системная оболочка сможет их отработать. Статус выхода 127 уникальным образом не идентифицирует этот класс ошибок и не предоставляет никакой детальной информации о природе сбоя. Обратите внимание на то, что разрешается (и даже поощряется) «ядерная» реализация функций posix_spawn() и posix_spawnp() с обеспечением возврата любых возможных ошибок в виде значений, возвращаемых этой функцией, тем самым предоставляя для родительского процесса более детальную информацию о происшедших сбоях.

Таким образом, для выделения асинхронных ошибок при выполнении функций posix_spawn() или posix_spawnp() упомянутые выше макросы не используются. О возможных ошибках, обнаруженных в контексте сыновнего процесса до того, как выполнится образ нового процесса, уведомление происходит путем установки статуса выхода сыновнего процесса равным значению 127. Вызывающий процесс для выявления сбоев при порождении процессов может использовать макросы WIFEXITED HWEXITSTATUS и значение stat_val, сохраненное функциями wait() или waitpid(), в тех случаях, когда другие значения статуса, с которыми может завершиться образ сыновнего процесса (до того, как родительский процесс сможет окончательно определить, что образ сыновнего процесса начал выполняться), отличаются от статуса выхода, равного числу 127.

Будущие направления

Отсутствуют.

Смотри также

alarm(), chmod(), close (), dup(), exec, exit (), fcntl (), fork(), kill (), open (),posix_spawn_file_actions_addclose(), posix_spawn_file_actions_adddup2(), posix_spawn_file_actions_addopen(), posix_spawn_file_actions_destroy() , <REFERENCE UNDEFINED> (posix_spawn_file_actions_init), posix_spawnattr_destroy(), posix_spawnattr_init(), posix_spawnattr_getsigdefault(), posix_spawnattr_getflags(), posix_spawnattr_getpgroup(), posix_spawnattr_getschedparam(), posix_spawnattr_getschedpolicy(), posix_spawnattr_getsigmask (), posix_spawnattr_setsigdefault (), posix_spawnattr_setflags(), posix_spawnattr_setpgroup(), posix_spawnattr_setschedparam (), posix_spawnattr_setschedpolicy (), posix_spawnattr_setsigmask (), sched__setparam (), sched_setscheduler (), setpgid (), setuid (), stat (), times (), wait () , то м Base Definitions стан д арта IEEEStd 1003.1-2001, <spawn.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 6, основанием послужил стандарт IEEEStdl003.1d-1999.

Применяется интерпретация IEEE PASC Interpretation 1003.1 #103, которая указывает, что в пункте 2 действия, соответствующие установкам сигналов по умолчанию, изменены так же, как маска сигналов.

При м еняется интерпретация IEEE PASC Interpretation 1003.1 #132.

posix_spawn_file_actions_addclose, posix_spawn_file_actions_addopen

Имя

posix_spawn_file_actions_addclose, posix_spawn_file_actions_addopen— функции внесения в объект действий над файла м и действия «закрыть файл» (или «открыть файл») (ADVANCED REALTIME).

Синопсис

SPN #include <spawn.h>

int posix__spawn_file_actions_addclose (

posix_spawn_file_actions_t *file_actions, int fildes); int posix_spawn_file_actions_addopen (

posix_spawn_file_actions_t *restrict file_actions, int fildes,

const char *restrict path, int oflag, mode_t mode) ;

Описание

Эти функции добавляют в объект действий над файла м и действие «закрыть файл» (или «открыть файл») или удаляют соответствую щ ее действие из это г о объекта.

Объект действий над файла м и и м еет тип posix_spawn_file_actions_t (который определен в за г оловке <spawn.h>) и используется для задания последовательности действий, подлежа щ их выполнению функция м и posix_spawn() или posix_spawnp() с целью получения для сыновне г о процесса м ножества открытых файловых дескрипторов в соответствии с м ножество м открытых файловых дескрипторов родительско г о процесса. Стандарт IEEE Std 1003.1-2001 не определяет для типа posix_spawn_file_actions_t операторы сравнения или присваивания.

Объект действий над файлами, передаваемый функции posix_spawn() или posix_spawnp (), определяет, как множество открытых файловых дескрипторов вызывающего процесса должно быть трансформировано во множество потенциально открытых файловых дескрипторов для порождаемого процесса. Эта трансформация должна выглядеть так, как если бы однократно была выполнена заданнал последовательность действий в контексте порожденного процесса (до выполнения образа нового процесса), причем в порядке, в котором эти действия были добавлены в объект. Кроме того, при выполнении образа нового процесса любой файловый дескриптор (из этого нового множества), у которого установлен флаг FD_CLOEXEC, должен быть закрыт (см. описание функции posix_spawn ()).

Функция posix_spawn_file_actions_addclose() добавляет в объект, адресуемый параметром file_actions, действие по закрытию файлов close, в результате чего при порождении нового процесса с использованием объекта действий файловый дескриптор, заданный параметром fildes, будет закрыт (как если бы была вызвана функция close (fildes)).

Функция posix_spawn_file_actions_addopen () добавляет в объект, адресуемый параметром file_actions, действие по открытию файлов орел, в результате чего при порождении ново г о процесса с использование м объекта действий файл, и м я которо г о зада н о пара м етро м path, будет открыт (как если бы была вызва н а функция open (path, oflag, mode) , и возвра щ енно м у ею файлово м у дескриптору, если он не равен значению fildes, будет присвоено значение fildes). Если дескриптор fildes относится к уже открыто м)' файлу, этот файл будет закрыт перед открытие м нового файла.

Строка, адресуе м ая пара м етро м path, копируется функцией posix_spawn_file_actions_addopen().

Возвращаемые значения

При успешном завершении эти функции возвращают нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Эти функции завершатся неудачно, если:

[EBADF] значение, заданное пара м етро м fildes, отрицательно либо больше или равно значению {OPEN_MAX}.

Выполнение этих функций м ожет завершиться неудачно, если: [EINVAL] значение, заданное пара м етро м file_actions, недопусти м о;

[ENOMEM] для расширения содержи м ого объекта действий над файлами недостаточно су щ ествую щ ей па м яти.

Не считается ошибкой, если в качестве значения аргу м ента fildes, передавае м ого эти м функция м, указа н файловый дескриптор, дл я которого задан н ал операция не м ожет быть выполнена во вре м я вызова. Любая подобнал ошибка будет обнаружена, когда соответствую щ ий объект действий над фай л а м и позже будет испо л ьзован при выпо л нении функции posix_spawn () и л и posix_spawnp ().

Примеры

Отсутствуют.

Замечания по использованию

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

Логическое обоснование

Объект действий над фай л а м и м ожно инициализировать с по м о щ ью упорядоченной пос л едовате л ьности операций close (), dup2 () и open (), предназначенной д л я испо л ьзования функция м и posix_spawn () и л и posix_spawnp () с це л ью получения м ножества открытых фай л овых дескрипторов, унас л едованных порожденны м процессо м от своего родите л я, и м ею щ е г о собственное м ножество открытых фай л овых дескрипторов в м о м ент вызова функции posix_spawn () и л и posix_spawnp (). Д л я реор г анизации фай л овых дескрипторов бы л о пред л ожено о г раничиться то л ько операция м и close () и dup2 (), а для то г о, чтобы порожденный процесс получил «в наследство» открытые файлы, м ожно посгупить дву м я способа м и: либо заставить вызывающий процесс открывать их перед вызово м функции posix_spawn() или posix_spawnp() (и закрывать их пото м), либо передавать и м ена нужных файлов в порожденный процесс (в аргу м енте argv), чтобы он м ог их открыть са м остоятельно. Разработчики стандарта реко м ендовали использовать на практике один из этих двух способов, поскольку детализированный статус ошибки в случае сбоя при выполнении операции открытия файла всегда доступен для приложения. Но разработчики стандарта по следую щ и м причина м все же считают воз м ожны м разрешить включение в объект действий над файла м и операцию open.

1. Это согласуется с эквивалентной функциональностью библиотеки POSIX .5 (Ada).

2. Это поддерживает парадигму перенаправления потоков ввода-вывода, часто применяемую POSIX-программами, предназначенными для вызова из оболочки. Если такая программа является сыновним процессом, ее можно сориентировать на самостоятельное открытие файлов.

3. Это позволяет сыновнему процессу открывать файлы, которые не должен открывать родительский процесс, поскольку операция по открытию файлов в этом случае может оказаться неудачной или нарушить права доступа к файлам (или права собственности).

Относительно приведенного выше п. 2 заметим, что действие «открыть файл» создает для функций posix_spawn () и posix_spawnp () те же возможности, что и операторы перенаправления для функции system(), но только без промежуточного выполнения оболочки. Например, так: system («myprog <filel 3<file2»);

Относительно приведенного выше п. 3 заметим, что если вызывающему процессу нужно открыть один или несколько файлов для доступа к ним порожденного процесса, но он обладает недостаточными запасами файловых дескрипторов, то выполнение действия open () необходимо позволить в контексте сыновнего процесса после того, как другие файловые дескрипторы (которые должны оставаться открытыми в родительском процессе) будут закрыты.

Кроме того, если родительский процесс выполняется из файла, для которого установлен бит режима «set-user-id» (идентификационный номер пользователя установлен) и в атрибутах порожденного процесса установлен флаг POSIX_SPAWN_RESETIDS, то файл, созданный в родительско м процессе, получит (воз м ожно, некорректно) в качестве владельца родительский ID эффективного пользователя, в то вре м я как файл, созданный действие м open() при выполнении функции posix_spawn() или posix_spawnp(), получит в качестве владельца реальный ID родительского процесса; при это м операция open, выполненнал родительски м процессо м, м ожет успешно открыть файл, к которо м у реальный пользователь не должен и м еть доступ, или неудачно открыть (т.е. не открыть) файл, к которо м у реальный пользователь должен и м еть доступ.

Преобразование файловых дескрипторов

Разработчики стандарта первоначально предлагали использовать массив, который бы определял преобразование файловых дескрипторов сыновнего процесса в обратном направлении, т.е. при переходе к родительскому процессу. Группа приема стандарта обратила внимание на то, что невозможно произвольно перетасовывать файловые дескрипторы в библиотечной реализации функции posix_spawn() или posix_spawnp (), не имея запаса файловых дескрипторов (которого попросту может не быть). Такой массив требует, чтобы реализация обладала сложной стратегией достижения нужного преобразования, которая бы исключала случайное закрытие «не того» файлового дескриптора в самое неподходящее время.

Одним из членов рабочей группы Ada Language Bindings было отмечено, что принятое в языке Ada семейство POSIX-примитивов Start_Process использует м ножество действий (задавае м ое инициаторо м вызова функции), чтобы изменить общепринятую семантику функций fork () /exec с целью наследования файловых дескрипторов довольно гибким способом, и пока никаких проблем не возникало, поскольку все бремя определения, как достичь конечного преобразования файловых дескрипторов, полностью лежит на приложении. Более того, хотя интерфейс, связанный с действиями над файлами, выглядит устрашающе сложным, в действительности он довольно прост для реализации либо в библиотеке, либо в ядре.

Будущие направления

Отсутствуют.

Смотри также

close (), dup (), open (), posix_spawn (), posix_spawn_file_actions_adddup2 (),

posix_spawn_file_actions_destroy (), posix_spawnp (), том Base Definitions стандарта IEEE Std 1003.1-2001, < spawn. h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 6, основание м послужил стандарт IEEEStd 1003.1d-1999.

При м еняется интерпретация IEEE PASC Interpretation 1003.1 #105, со г ласно которой в раздел «Описание» было внесено дополнение о то м, что строка, адресуе м ал пара м етро м path, копируется функцией posix_spawn_file_actions_addopen ().

posix_spawn_file_actions_adddup2

Имя

posix_spawn_file_actions_adddup2— функция внесения в объект действий над файла м и действия dup2 (ADVANCED REALTIME).

Синопсис

SPN #include <spawn.h>

int posix_spawn_file_actions_adddup2 (

posix_spawn_file_actions_t * file_aсtions, int fildes, int newfildes);

Описание

Функция posix_spawn_file_actions_adddup2() добавляет в объект, адресуе м ый пара м етро м file_actions, действие dup2(), в результате чего при порождении нового процесса с использование м объекта действий файловый дескриптор fildes дублируется в пара м етр newfildes (как если бы была вызвана функция dup2 ( fildes, newfildes)).

Объект действий над файла м и порожденного процесса определяется в описании функции posix_spawn_file_actions_addclose().

Возвращаемое значение

При успешно м завершении функция posix_spawn_file_actions_adddup2() возвра щ ает нулевое значение; в противно м случае — код ошибки, обозначаю щ ий ее характер.

Ошибки

Функция posix_spawn_file_actions_adddup2 () завершится неудачно, если:

[EBADF] значение, заданное пара м етро м fildes или newfildes, отрицательно либо больше или равно значению {0PEN_MAX};

[EN0MEM] для расширения содержи м ого объекта действий над файла м и недостаточно су щ ествую щ ей па м яти.

Выполнение фу н кции posix_spawn_file_actions_adddup2() м ожет завершиться неудачно, если:

[EINVAL] значение, заданное пара м етро м file_actions, недопусти м о.

Не считается ошибкой, если в качестве значения аргу м ента fildes, передавае м ого функции posix_spawn_file_actions_adddup2(), указан файловый дескриптор, для которо г о заданная операция не м ожет быть выполнена во вре м я вызова. Любая подобная ошибка будет обнаружена, ко г да соответствую щ ий объект действий над файла м и позже будет использован при выполнении функции posix_spawn () или posix_spawnp ().

Примеры

Отсутствуют.

Замечания по использованию

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

Логическое обоснование

С м отрите раздел «Ло г ическое обоснование» в описании функции posix_spawn__file_actions_addclose().

Будущие направления

Отсутствуют.

Смотри также

dup (), posix_spawn (), posix_spawn_file_actions_addclose (), posix_spawn_file_actions_destroy (), posix_spawnp (), том Base Definitions стандарта IEEE Std 1003.1-2001, <spawn. h>.

Последовательность внесения изменений

Функция впервые реализована в выпуске Issue 6, основание м послужил стандарт IEEEStdl003.1d-1999.

При м еняется интерпретация IEEE PASC Interpretation 1003.1 #104, в которой указывается, что ошибка [EBADF], по м и м о аргу м ента fildes, м ожет быть при м ени м а к аргу м енту newfildes.

posix_spawn_file_actions_destroy, posix_spawn_file_actions_init

Имя

posix_spawn_file_actions_destroy, posix_spawn_file_actions_init — функции разрушения и инициализации объекта действий над файла м и для порожде н но г о процесса (ADVANCED REALTIME).

Синопсис

SPN #include <spawn.h>

int posix_spawn_file_actions_destroy (posix_spawn_file_actions_t *file___actions) ;

int posix_spawn_file_actions_init (posix_spawn_file_actions_t *file_actions);

Описание

Функция posix_spawn_file_actions_destroy() предназначена для разрушения объекта, адресуе м о г о пара м етро м file_actions; после ее при м енения объект становится неинициализированны м. В конкретной реализации функция posix_spawn_file_actions_destroy() м ожет устанавливать объект, адресуе м ый пара м етро м file_actions, равны м недействительно м у значению. Разрушенный объект действий над файла м и м ожно снова инициализировать с по м о щ ью функции posix_spawn_file_actions_init(); результаты ссылки на этот объект после е г о разрушения не определены.

Функция posix_spawn_file_actions_init () используется для инициализации объекта, адресуемого параметром file_actions; после ее при м енения объект не будет содержать никаких действий, предназначенных для выполнения над файла м и при вызове функций posix_spawn () или posix_spawnp ().

Объект действий над файла м и порожденно г о процесса определяется в описании функции posix_spawn_file_actions_addclose(). Результат инициализации уже инициализированно г о объекта действий над файла м и не определен.

Возвращаемые значения

При успешно м завершении эти функции возвра щ ают нулевое значение; в противно м случае — код ошибки, обозначаю щ ий ее характер.

Ошибки

Функция posix_spawn_file_actions_init () завершится неудачно, если:

[EN0MEM]  для и ниц и ализаци и объекта действий над файла м и недостаточно су щ ествую щ ей па м яти.

Функция posix_spawn_file_actions_destroy() м ожет завершиться неудачно, если:

[EINVAL]

значение, заданное пара м етро м file_actions, недопусти м о.

Примеры

Отсутствуют.

Замечания по использованию

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

Логическое обоснование

С м отрите раздел «Логическое обоснование» в описании функции posix_spawn_file_actions_addclose().

Будущие направления

Отсутствуют.

Смотри также

posix_spawn (), posix_spawnp (), том Base Definitions стандарта IEEE Std 1003.1-2001, <spawn.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 6, основание м послужил стандарт IEEE Std 1003.1d-1999.

В разделе «Синопсис» включение заголовка <sys/types.h> больше не требуется.

posix_spawnattr_destroy, posix_spawnattr_init

Имя

posix_spawnattr_destroy, posix_spawnattr_init— функции разрушения и инициализации объекта атрибутов порожденно г о процесса (ADVANCED REALTIME).

Синопсис

SPN #include <spawn.h>

int posix_spawnattr_destroy (posix_spawnattr_t *attr); int posix_spawnattr_init (posix_spawnattr_t *attr);

Описание

Функция posix_spawnattr_destroy() предназначена для разрушения объекта атрибутов порожденного процесса. Разрушенный объект атрибутов, адресуемый параметром attr, можно снова инициализировать с помощью функции posix_spawnattr_init (); результаты ссылки на этот объект после его разрушения не определены. В конкретной реализации функция posix_spawnattr_destroy() может устанавливать объект, адресуемый параметром attr, равным некоторому недействительному значению.

Функция posix_spawnattr_init() служит для инициализации объекта атрибутов порожденного процесса, адресуемого параметром attr, значениями, действующими по умолчанию для всех отдельных атрибутов, используемых конкретной реализацией. Результат вызова функции posix_spawnattr_init () не определен, если заданный параметром attr объект атрибутов уже инициализирован.

Объект атрибутов порожденного процесса имеет тип posix_spawnattr_t (определен в заголовке <spawn.h>) и используется для задания наследования атрибутов процесса при выполнении операции порождения процесса. Для типа posix_spawnattr_t операторы сравнения и присваивания стандарт IEEE Std 1003.1-2001 не определяет.

Для каждой реализации должны быть описаны отдельные атрибуты, которые она использует, и их стандартные значения, если они не определены стандартом IEEE Std ЮОЗ.1-2001. Атрибуты, не определенные стандартом IEEE Std 1003.1-2001, их стандартные значения и имена соответствующих функций чтения и записи этих атрибутов определяются конкретной реализацией.

Результирующий объект атрибутов порожденного процесса (возможно, модифицированный путем установки значений отдельных атрибутов) используется для модификации поведения функций posix_spawn () или posix_spawnp (). После того как объект атрибутов был использован для порождения процесса путем вызова функции posix_spawn () или posix_spawnp(), любая функция, способная изменить объект атрибутов (включая функцию разрушения), не может повлиять на процесс, соз д анный таки м способо м.

Возвращаемые значения

При успешно м завершении функции posix_spawnattr_destroy() и posix_spawnattr_init() возвра щ ают нулевое значение; в противно м случае — ко д ошибки, обозначаю щ ий ее характер.

Ошибки

Функция posix_spawnattr_init () завершится неудачно, если:

[ ENOMEM ] для инициализации объекта атрибутов недостаточно существующей памяти.

Функция posix_spawnattr_destroy () м ожет завершиться неудачно, если:

[EINVAL ] з н ачение, заданное пара м етро м attr, недопусти м о.

Примеры

Отсутствуют.

Замечания по использованию

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

Логическое обоснование

Исходный интерфейс, предложенный в стандарте IEEE Std 1003.1-2001, определял атрибуты, наследуемые при выполнении операции порождения процесса, в виде структуры. Чтобы иметь возможность выделить некоторые необязательные атрибуты в отдельные опции (например, атрибуты spawn-schedparamn spawn-schedpolicy относятся к опции Process Scheduling), а также с целью расширяемости и совместимости с более новыми POSIX-интерфейсами, для интерфейса атрибутов был изменен тип данных. Этот интерфейс в настоящее время состоит из типа posix_spawnattr_t, представляющего объект атрибутов порожденного процесса, и соответствующих функций, которые позволяют инициализировать или разрушить этот объект атрибутов, а также установить или получить значение каждого отдельного атрибута. Несмотря на то что новый объектно-ориентированный интерфейс более сложен, чем исходнал структура, его проще использовать, легче наращивать и реализовывать.

Будущие направления

Отсутствуют.

Смотри также

posix_spawn (), posix_spawnattr_getsigdefault (), posix_spawnattr_getflags (), posix_spawnattr_getpgroup (), posix_spawnattr_getschedparam(), posix_spawnattr_getschedpolicy (), posix_spawnattr_getsigmask(),posix_spawnattr_setsigdefault(), posix_spawnattr_setflags(), posix_spawnattr_setpgroup(), posix_spawnattr_setsigmask(), posix_spawnattr_setschedpolicy(), posix_spawnattr_setschedparam (), posix_spawnp (), то м Base Definitions стан д арта IEEEStd 1003.1-2001, <spawn.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 6, основанием послужил стандарт IEEE Std 1003.1d-1999.

При м еняется интерпретация IЕЕЕ PASC Interpretation 1003.1 #106, в которой отмечается, что результат инициализации уже инициализированного объекта атрибутов не определен.

posix_spawnattr_getflags, posix_spawnattr_setflags

Имя

posix_spawnattr_getflags, posix_spawnattr_setflags— функции считывания и установки атрибута spawn-flags из объекта атрибутов порож д енного процесса (ADVANCED REALTIME).

Синопсис

SPN #include < spawn.h>

int posix_spawnattr_getflags (const posix_spawnattr_t *restrict attr, short *restrict flags);

int posix_spawnattr_setflags (posix_spawnattr_t *attr, short flags);

Описание

Функция posix_spawnattr_getflags () пре д назначена д ля получения значения атрибута spawn-flags из объекта атрибутов, адресуе м ого пара м етро м attr.

Функция posix_spawnattr_setflags () пре д назначена д ля установки значения атрибута spawn-flags в инициализированно м объекте атрибутов, адресуе м о м пара м етро м аttr.

Атрибут spawn-flags используется д ля обозначения того, какие атрибуты процесса должны быть изменены в образе нового процесса при вызове функции posix_spawn() или posix_spawnp(). Этот атрибут представляет собой результат применения поразрядной операции включающего ИЛИ к некоторому числу (которое может быть нулевым) следующих флагов:

POSIX_SPAWN_RESETIDS

POSIX_SPAWN_SETPGROUP

POSIX_SPAWN_SETSIGDEF

POSIX_SPAWN_SETSIGMASK

PS

POSIX_SPAWN_SETSCHEDPARAM

POSIX_SPAWN_SETSCHEDULER

Эти флаги определены в заголовке <spawn.h>. Значение, действую щ ее по у м олчанию для этого атрибута, должно соответствовать ситуации, при которой ни один флаг не установлен.

Возвращаемые значения

При успешном выполнении функция posix_spawnattr_getflags () возвращает нулевое значение и сохраняет значение атрибута spawn-flags из объекта атрибутов, адресуе м ого пара м етро м attr, в объекте, адресуе м о м пара м етро м flags; в противном случае возвращается код ошибки, обозначающий ее характер.

При успешном выполнении функция posix_spawnattr_setflags () возвращает нулевое значение, в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Эти функции м огут завершиться неу д ачно, если: [EINVAL]  значение, заданное пара м етро м attr, не д опусти м о.

Функция posix_spawnattr__setflags () м ожет завершиться неу д ачно, если:

[ EINVAL ]  устанавливаемое значение атрибута недопустимо.

Примеры

Отсутствуют.

Замечания по использованию

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

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

posix_spawn (), posix_spawnattr_destroy (), posix_spawnattr_init (), posix_spawnattr_getsigdefault (), posix_spawnattr_getpgroup (), posix_spawnattr_getschedparam(), posix_spawnattr_getschedpolicy(), posix_spawnattr_getsigmask (), posix_spawnattr_setsigdefault (), posix_spawnattr_setpgroup (), posix_spawnattr_setschedparam(), posix_spawnattr_setschedpolicy (), posix_spawnattr_setsigmask (), posix_spawnp (), том Base Definitions стан д арта IEEE Std 1003.1-2001, <spawn. h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 6, основанием послужил стан д арт IEEE Std 1003.1d-1999.

posix_spawnattr_getpgroup, posix_spawnattr_setpgroup

Имя

posix_spawnattr_getpgroup, posix_spawnattr_setpgroup— функции считывания и установки атрибута spawn-pgroup из объекта атрибутов порожденного процесса (ADVANCED REALTIME).

Синопсис

SPN #include <spawn.h>

int posix_spawnattr_getpgroup (

const posix_spawnattr_t *restrict attr,

pid_t *restrict pgroup); int posix_spawnattr_setpgroup (posix_spawnattr_t *attr,

pid_t pgroup) ;

Описание

Функция posix_spawnattr_getpgroup() предназначена для получения значения атрибута spawn-pgroup из объекта атрибутов, адресуе м ого пара м етро м attr.

Функция posix_spawnattr_setpgroup () позволяет установить атрибут spawn-pgroup в инициализированно м объекте атрибутов, адресуе м о м пара м етро м attr.

Атрибут spawn-pgroup представляет группу процессов, к которой при выполнении операции порождения процесса присоединяется новый процесс (если в атрибуте spawn-flags установлен флаг POSIX_SPAWN_SETPGROUP). По у м олчанию значение этого атрибута равно нулю.

Возвращаемые значения

При успешном выполнении функция posix_spawnattr_getpgroup () возвращает нулевое значение и сохраняет значение атрибута spawn-pgroup из объекта атрибутов, адресуемого параметром attr, в объекте, адресуемом параметром pgroup\ в противном случае возвращается код ошибки, обозначающий ее характер.

При успешном выполнении функция posix_spawnattr_setgroup () возвращает нулевое значение, в противном случае — код ошибки, обозначаю щ ий ее характер.

Ошибки

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

[EINVAL]  значение, заданное пара м етро м attr, недопусти м о.

Функция posix_spawnattr_setgroup () м ожет завершиться неудачно, если:

[ EINVAL ]  устанавливае м ое значение атрибута недопусти м о.

Примеры

Отсутствуют.

Замечания по использованию

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

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

posix_spawn(), posix_spawnattr_destroy(),posix_spawnattr_init(), posix_spawnattr_getsigdefault(), posix_spawnattr_getflags(), posix_spawnattr_getschedparam(), posix_spawnattr_getschedpolicy(), posix_spawnattr_getsigmask(), posix_spawnattr_setsigdefault(), posix_spawnattr_setflags (), posix_spawnattr_setschedparam(), posix_spawnattr_setschedpolicy(), posix_spawnattr_setsigmask(), posix_spawnp (), том Base Deflnitions стан д арта IEEE Std 1003.1-2001, <spawn.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 6, основанием послужил стандарт IEEE Std 1003.1d-1999.

posix_spawnattr_getschedparam, posix_spawnattr_setschedparam

Имя

posix_spawnattr_getschedparam, posix_spawnattr_setschedparam

функции считывания и установки атрибута spawn-schedparam из объекта атрибутов порожденного процесса (ADVANCED REALTIME).

Синопсис

SPNPS #include <spawn.h>

#include <sched.h>

int posix_spawnattr_getschedparam (const posix_spawnattr_t *restrict attr, struct sched_param *restrict schedparam) ;

int posix_spawnattr_setschedparam (posix_spawnattr_t *restrict attr, const struct sched_param *restrict schedparam) ;

Описание

Функция posix_spawnattr_getschedparam() предназначена для получения значения атрибута spawn-schedparamn3 объекта атрибутов, адреcуемого параметром attr.

Функция posix_spawnattr_setschedparam() позволяет установить атрибут spawn-schedparam в инициализированно м объекте атрибутов, адресуе м о м пара м етро м аttr.

Атрибут spawn-schedparam представляет пара м етры стратегии планирования, присваивае м ые образу нового процесса при выполнении операции порождения процесса (если в атрибуте spawn-flags установлен флаг POSIX_SPAWN_SETSCHEDULER или флаг POSIX_SPAWN_SETSCHEDPARAM). По у м олчанию значение этого атрибута не задано.

Возвращаемые значения

При успешном выполнении функция posix_spawnattr_getschedparam() возвращает нулевое значение и сохраняет значение атрибута spawn-schedparam из объекта атрибутов, адреcуемого пара м етро м attr, в объекте, адреcуемом параметро м schedparam, в противно м случае возвращается код ошибки, обозначающий ее характер.

При успешно м выполнении функция posix_spawnattr_setschedparam() возвращает нулевое значение, в противном случае — код ошибки, обозначающий ее характер.

Ошибки

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

[ EINVAL]  значение, заданное пара м етро м attr , недопусти м о.

Функция posix_spawnattr_setschedparam () м ожет завершиться неудачно, если:

[ EINVAL ]  устанавливае м ое значение атрибута недопусти м о.

Примеры

Отсутствуют.

Замечания по использованию

Эти функции являются частью опций Spawn и Process Scheduling и могут быть не представлены во всех реализациях.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

posix_spawn (), posix_spawnattr_destroy (), posix_spawnattr_init (), posix_spawnattr_getsigdefault(), posix_spawnattr_getflags(), posix_spawnattr_getpgroup(), posix_spawnattr_getschedpolicy(), posix_spawnattr_getsigmask(), posix_spawnattr_setsigdefault(), posix_spawnattr_setflags(), posix_spawnattr_setpgroup(), posix_spawnattr_setschedpolicy(), posix_spawnattr_setsigmask(), posix_spawnp (), том Base Definitions стан д арта IEEE Std 1003.1-2001, <sched.h>, <spawn.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 6, основанием послужил стандарт IEEE Std 1003.1d-1999.

posix_spawnattr_getschedpolicy, posix_spawnattr_setschedpolicy

Имя

posix_spawnattr_getschedpolicy, posix_spawnattr_setschedpolicy — функции считывания и установки атрибута spawn-schedpolicy из объекта атрибутов порожденного процесса (ADVANCED REALTIME).

Синопсис

SPN #include <spawn.h>

#include <sched.h>

int posix_spawnattr_getschedpolicy (const posix_spawnattr_t *restrict attr, int *restrict schedpolicy) ;

int posix_spawnattr_setschedpolicy (

posix_spawnattr_t *attr, int schedpolicy);

Описание

Функция posix_spawnattr_getschedpolicy() предназначена для получения значения атрибута spawn-schedpolicy из объекта атрибутов, адресуемого параметром attr.

Функция posix_spawnattr_setschedpolicy () позволяет установить атрибут spawn-schedpolicy в инициализированно м объекте атрибутов, адресуемом параметром attr.

Атрибут spawn-schedpolicy представляет стратегию планирования, назначаемую образу нового процесса при выполнении операции порождения процесса (если в атрибуте spawn-flags установлен флаг POSIX_SPAWN_SETSCHEDULER). П о умолчанию значение этого атрибута не задано.

Возвращаемые значения

П ри успешном выполнении функция posix_spawnattr_getschedpolicy () возвра щ ает нулевое значение и сохраняет значение атрибута spawn-schedpolicy из объекта атрибутов, адреcуемого параметром attr, в объекте, адреcуе м о м пара м етро м schedpolicy в противно м случае возвра щ ается код ошибки, обозначаю щ ий ее характер.

П ри успешно м выполнении функция posix_spawnattr_setschedpolicy() возвра щ ает нулевое значение, в противно м случае — код ошибки, обозначаю щ ий ее характер.

Ошибки

Выполнение этих функций м ожет завершиться неудачно, если: [ EINVAL ]  значение, заданное пара м етро м attr, недопустимо.

Функция posix_spawnattr_setschedpolicy () можетзавершиться неудачно, если: [ EINVAL ]  устанавливаемое значение атрибута недопустимо.

Пр и ложе ни е Б 535

Примеры

Отсутствуют.

Замечания по использованию

Эти функции являются частью опций Spawn и Process Scheduling и могут быть не пре д ставлены во всех реализациях.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

posix_spawn (), posix_spawnattr_destroy (), posix_spawnattr_init (), posix_spawnattr_getsigdefault(), posix_spawnattr_getflags(), posix_spawnattr_getpgroup (), posix_spawnattr_getschedparam(), posix_spawnattr_getsigmask (), posix_spawnattr_setsigdefault (), posix_spawnattr_setflags(), posix_spawnattr_setpgroup(), posix_spawnattr_setschedparam(), posix_spawnattr_setsigmask(), posix_spawnp (), том Base Definitions стандарта1ЕЕЕ Std 1003.1-2001, <sched.h>, <spawn.h>

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 6, основанием послужил стандарт IEEE Std 1003.1d-1999.

posix_spawnattr_getsigdefault, posix_spawnattr_setsigdefault

Имя

posix_spawnattr_getsigdefault, posix_spawnattr_setsigdefault —

функции считывания и установки атрибута spawn-sigdefault из объекта атрибутов порожденного процесса (ADVANCED REALTIME).

Синопсис

SPN

#include <signal.h>

#include <spawn.h>

int posix_spawnattr_getsigdefault (

const posix_spawnattr_t *restrict attr, sigset_t *restrict sigdefault);

int posix_spawnattr_setsigdefault (

posix_spawnattr_t *restrict attr, const sigset_t *restrict sigdefault);

Описание

Функция posix_spawnattr_getsigdefault() предназначена для получения значения атрибута spawn-sigdefault из объекта атрибутов, адресуе м ого параметром аttr.

Функция posix_spawnattr_setsigdefault() позволяет установить атрибут spawn-sigdefault в инициализированном объекте атрибутов, адресуемо м пара м етро м аttr.

Атрибут spawn-sigdefault представляет м ножество сигналов, которые должны быть подвергнуты обработке по у м олчанию в образе нового процесса (если в атрибуте spawn-flags установлен флаг POSIX_SPAWN_SETSIGDEF) при выполнении операции порождения процесса. По у м олчанию значение этого атрибута представляет собой пустое м ножество сигналов.

Возвращаемые значения

При успешно м выполнении функция posix_spawnattr_getsigdefault() возвра щ ает нулевое значение и сохраняет значение атрибута spawn-sigdefaul t из объекта атрибутов, адресуе м о г о пара м етро м attr, в объекте, адреcуемом пара м етро м sigdefault, в противном случае возвращается код ошибки, обоз н ачаю щ ий ее характер.

При успешно м выполнении функция posix_spawnattr_setsigdefault() возвра щ ает нулевое значение, в противно м случае — код ошибки, обозначающий ее характер.

Ошибки

Выполнение этих функций м ожет завершиться неудачно, если: [EINVAL]  значение, заданное пара м етро м attr, недопусти м о.

Функция posix_spawnattr_setsigdefault () м ожет завершиться неудачно, если: [ EINVAL ]  устанавливае м ое значение атрибута недопусти м о.

Примеры

Отсутствуют.

Замечания по использованию

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

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

posix_spawn (), posix_spawnattr_destroy (), posix_spawnattr_init (), posix_spawnattr_getflags (), posix_spawnattr_getpgroup (), posix_spawnattr_getschedparam(), posix_spawnattr_getschedpolicy (), posix_spawnattr_getsigmask (), posix_spawnattr_setflags (), posix_spawnattr_setpgroup (), posix_spawnattr_setschedparam(), posix_spawnattr_setschedpolicy(), posix_spawnattr_setsigmask (), posix_spawnp (), том Base Definidons стандарта IEEE Std 1003.1-2001, <signal. h>, <spawn.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 6, основанием послужил стандарт IEEE Stdl003.1d-1999.

posix_spawnattr_getsigmask, posix_spawnattr_setsigmask

Имя

posix_spawnattr_getsigmask, posix_spawnattr_setsigmask— функции считывания и установки атрибута spawn-sigmask из объекта атрибутов порожденного процесса (ADVANCED REALTIME).

Синопсис

SPN #include <signal.h>

#include <spawn.h>

int posix_spawnattr_getsigmask (

const posix_spawnattr_t *restrict attr, sigset_t *restrict sigmask); int posix_spawnattr_setsigmask (

posix_spawnattr_t *restrict attr, const sigset_t *restrict sigmask);

Описание

Функция posix_spawnattr_getsigmask() предназначена для получения значения атрибута spawn-sigmask объекта атрибутов, адресуе м ого пара м етро м attr.

Функция posix_spawnattr_setsigmask() позволяет установить атрибут spawn-sigmask в инициализированном объекте атрибутов, адресуемом параметром attr .

Атрибут spawn-sigmask представляет м аску сигналов, предназначен н ую для использования в образе нового процесса при выполнении операции порождения процесса (если в атрибуте spawn-flags установлен флаг POSIX_SPAWN_SETSIGMASK). По у м олчанию значение этого атрибута не определено.

Возвращаемые значения

При успешно м выполнении функция posix_spawnattr_getsigmask() возвращает нулевое значение и сохраняет значение атрибута spawn-sigmask из объекта атрибутов, адресуе м ого пара м етро м attr, в объекте, адресуе м о м пара м етро м sigmask; в противно м случае возвращается код ошибки, обозначающий ее характер.

При успешно м выполнении функция posix_spawnattr_setsigmask() возвращает нулевое значение, в противно м случае — код ошибки, обозначающий ее характер.

Ошибки

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

[EINVAL]   значение, заданное пара м етро м аttr, недопусти м о.

Функция posix_spawnattr_setsigmask () может завершиться неудачно, если:

[EINVAL ]  устанавливаемое значение атрибута недопустимо.

Примеры

Отсутствуют.

Замечания по использованию

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

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

posix_spawn (), posix_spawnattr_destroy (), posix_spawnattr_init (), posix_spawnattr_getsigdefault(), posix_spawnattr_getflags(), posix_spawnattr_getpgroup (), posix_spawnattr_getschedparam(), posix_spawnattr_getschedpolicy(), posix_spawnattr_setsigdefault(), posix_spawnattr_setflags (), posix_spawnattr_setpgroup (), posix_spawnattr_setschedparam(), posix_spawnattr_setschedpolicy(), posix_spawnp (), том Base Definitions стандарта IEEE Std 1003.1-2001, <signal. h>, <spawn.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 6, основанием послужил стандарт IEEEStd 1003.1d-1999.

pthread_attr_destroy, pthread_attr_init

Имя

pthread_attr_destroy, pthread_attr_init — функции разрушения и инициализации объекта атрибутов потока.

Синопсис

THR #include <pthread.h>

int pthread_attr_destroy (pthread_attr_t *attr); int pthread_attr_init (pthread_attr_t *attr);

Описание

Функция pthread_attr_destroy() предназначена для разрушения объекта атрибутов потока. В конкретной реализации функция pthread_attr_destroy() м ожет устанавливать пара м етр аttr равны м некоторо м у недействительно м у значению, определяе м о м у реализацией. Разрушенный объект атрибутов, адресуе м ый пара м етро м attr, м ожно инициализировать повторно с по м ощью функции pthread_attr_init (); результаты ссылки на этот объект после его разрушения не определены.

Функция pthread_attr_init() позволяет инициализировать объект атрибутов потока, адресуемый параметром attr, значением, действующим по умолчанию для всех отдельных атрибутов, используемых в данной реализации.

Результирующий объект атрибутов (воз м ожно, м одифицированный путе м установки значений отдельных атрибутов) при выполнении функции pthread_create () определяет атрибуты создавае м о г о потока. В нескольких одновре м енных вызовах функции pthread_create () м ожно использовать один объект атрибутов. Результат вызова функции pthread_attr_init () не определен, если заданный пара м етро м attr объект атрибутов уже инициализирован.

Возвращаемые значения

При успешно м завершении эти функции возвращают нулевое значение; в противно м случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_attr_init () завершится неудачно, если:

[ENOMEM] для инициализации объекта атрибутов потока недостаточно существующей па м яти.

Эти функции не возвращают код ошибки в виде значения [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствует.

Логическое обоснование

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

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

Объекты атрибутов можно использовать для создания классов потоков с аналогичными атрибутами; например, «потоков с большими стеками и высоким приоритетом» или «потоков с минимальными стеками». Эти классы можно определить в одном месте программы, а затем их использовать, когда понадобится создать поток. В результате значительно упростится процесс изменения «классовых» решений потоков, и не придется подробно анализировать каждый вызов функции pthread_create ().

Объекты атрибутов с целью потенциальной расширяемости определяются как «закрытые» типы. Если бы они были определены как «прозрачные» структуры, то при добавлении новых атрибутов (т.е. при расширении объектов атрибутов) пришлось бы перекомпилировать все многопоточные программы, что не всегда возможно, например, если различные программные компоненты приобретены у различных изготовителей.

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

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

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

1. Поддерживается стиль передачи функциям инициализации (pthread_create (), pthread_mutex_init (), pthread_cond_init ()) параметра, формируемого пу-тем применения поразрядной операции включающего ИЛИ к флагам. Содержащий эти флаги параметр (в расчете на расширяемость в булущем) должен иметь «непрозрачный» тип. Если в этом параметре флаги не установлены, то объекты создаются с использованием характеристик, действующих по умолчанию. Реализация самостоятельно может задавать значения флагов и соответствующее им поведение.

2. Если необходима дальнейшая специализация мьютексов и условных переменных, в реализациях могут быть определены дополнительные процедуры, предназначенные для выполнения действий над объектами типа pthread_mutex_t и pthread_cond_t (а не над объектами атрибутов).

При внедрении этого решения возможны следующие трудности.

1. Побитовая маска не будет считаться «закрытой», если биты должны быть установлены в векторных объектах атрибутов с использованием явно закодированных поразрядных операций включающего .ИЛИ. Если количество опций превышает размер типа int, прикладные программисты должны знать местоположение каждого бита. Если биты устанавливаются или считываются путем средств инкапсуляции (т.е. с помощью функций считывания и установки), то побитовал маска будет представлять собой всего лишь реализацию объектов атрибутов без свободного доступа для программиста.

2. Многие атрибуты имеют тип, отличный от булевого, или представляют собой малые целые значения. Например, для задания стратегии планирования можно выделить 3 или 4 бит, но для приоритета потребуется 5 или больше бит, следовательно по меньшей мере 8 из 16 возможных бит (для компьютеров с 16-разрядными целочисленными значениями) уже «занято». Поэтому побитовая маска может корректно управлять только атрибутами булевого типа («установлен» или нет) и не может служить в качестве хранилища для значений иного типа. Такие значения необходимо задавать или в качестве параметров функций (которые не относятся к числу наращиваемых), или путем установки полей структуры (которые не являются «закрытыми»), или с помощью функций доступа, т.е. функций считывания и записи (которые делают побитовую маску излишним дополнением к объектам атрибутов).

Размер стека определяется как необязательный атрибут, поскольку само понятие стека зависит от конкретного компьютера. Например, в одних реализациях невозможно изменить размер стека, а в других в этом вообще нет необходимости, поскольку страницы стека могут быть несмежными и выделяться (и освобождаться) по требованию.

Механизм атрибутов разработан по большей мере ради расширяемости. Будущие дополнения к механизму атрибутов или любому объекту атрибутов, определенному в этом томе (разделе) стандарта IEEE Std 1003.1-2001, необходимо вносить с чрезвычайной тщательностью, чтобы они не отразились на совместимости на уровне машинных кодов.

Объекты атрибутов, даже создаваемые с помощью таких функций динамического распределения памяти, как malloc(), во время компиляции могут иметь фиксированный размер. Это означает, например, что функция pthread_create () в реализации с дополнениями для использования типа pthread_attr_t не сможет «видеть» за пределами области, которую двоичное приложение считает допустимой. Это говорит о том, что реализации должны поддерживать в объекте атрибутов поле размера, а также информацию о версии, если дополнения приходится использовать в различных направлениях (или объединять продукты различных изготовителей).

Будущие направления

Отсутствуют.

Смотри также

pthread_attr_getstackaddr(), pthread_attr_getstacksize(), pthread_attr_getdetachstate (), thread_create (), том Base Definidons стандарта IEEEStd 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширение м POSIX Threads Extension.

Issue 6

Функции pthread_attr_destroy() и pthread_attr_init() от м ечены как часть опции Threads.

При м еняется интерпретация IEEE PASC Interpretation 1003.1 #107, в которой указывается, что результат инициализации уже инициализированного объекта атрибутов потока не опре д елен.

pthread_attr_getdetachstate, pthread_attr__setdetachstate

Имя

pthread_attr_getdetachstate, pthread_attr__setdetachstate — функции считывания и записи атрибута detachstate.

Синопсис

THR #include <pthread.h>

int pthread_attr_getdetachstate (

const pthread_attr_t *attr, int *detachstate) ;

int pthread_attr_setdetachstate (pthread_attr_t *attr,

int detachstate) ;

Описание

Атрибут detachstate управляет тем, создается ли поток в открепленно м (отсоединенно м) состоянии. Если поток создается открепленным, то использование его идентификационного но м ера (ID) функция м и pthread_detach() или pthread_join () является ошибкой.

Функции pthread_attr_getdetachstate() и pthread_attr_setdetachstate() считывают и устанавливают соответственно атрибут detachstate в объекте атрибутов, адресуе м о м пара м етро м аttr.

С по м ощью функции pthread_attr_setdetachstate() приложение м ожет установить атрибут detachstate равны м либо значению PTHREAD_CREATE_DETACHED, либо значению PTHREAD_CREATE_JOINABLE.

С по м ощью функции pthread_attr_getdetachstate () считывается значение атрибута detachstate, которое м ожет быть равны м либо PTHREAD_ CREATE_DE TACHED, либо PTHREAD_CREATE_JO INABLE.

Значение PTHREAD_CREATE_DETACHED используется для перевода всех потоков, создавае м ых с по м ощью объекта, адресуе м ого пара м етро м attr, в открепленное состояние, в то вре м я как значение PTHREAD_CREATE_JO INABLE при м еняется для перевода всех потоков, создавае м ых с по м ощью объекта, адресуе м ого пара м етро м attr, в присоединенное состояние. По у м олчанию атрибут detachstate устанавливается равны м значению PTHREAD_CREATE_JO INABLE.

Возвращаемые значения

При успешно м завершении функции pthread_attr_getdetachstate () и pthread_attr_setdetachstate() возвращают нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Функция pthread_attr_getdetachstate() при успешно м выполнении сохраняет значение атрибута detachstate в пара м етре detachstate.

Ошибки

Функция pthread_attr_setdetachstate () завершится неу д ачно, если: [EINVAL ] значение, за д анное пара м етро м de tachsta te, недействительно. Эти функции не возвра щ ают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствует.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_attr_destroy (), pthread_attr_getstackaddr (),

pthread_attr_getstacksize (), pthread_create (), том Base Definidons стандарта IEEEStd 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширением POSIX Threads Extension.

Issue 6

Функции pthread_attr_getdetachstate() и pthread_attr_setdetachstate () от м ечены как часть опции Threads.

Раздел «Описание» был отредактирован с целью исключить из него слово «must» («должен»).

pthread_attr_getguardsize, pthread_attr_setguardsize

Имя

pthread_attr_getguardsize, pthread_attr_setguardsize— функции считывания и установки значения потоково г о атрибута guardsize.

Синопсис

XSI #include <pthread.h>

int pthread_attr_getguardsize (

const pthread_attr_t *restrict attr, size_t *restrict guardsize);

int pthread_attr_setguardsize (pthread_attr_t *attr,

size_t guardsize);

Описание

Функция pthread_attr_getguardsize () используется для считывания атрибута guardsize из объекта атрибутов, адресуе м ого пара м етро м attr. Этот атрибут возвращается в пара м етре guardsize.

Функция pthread_attr_setguardsize () позволяет установить атрибут guardsize в объекте атрибутов, адресуемом параметром аttr. Новое значение этого атрибута записывается из пара м етра guardsize. Если значение пара м етра guardsize равно нулю, то для потоков, создавае м ых с использование м атрибута attr, защищенная область не предоставляется. Если значение пара м етра guardsize больше нуля, то для каждого потока, создавае м ого с использование м атрибута attr, предоставляется защищенная область, раз м ер которой составляет не м енее guardsize байтов.

Атрибут guardsize позволяет управлять размером защищенной области, выделяемой для стека создаваемого потока. Атрибут guardsize обеспечивает защиту от адресного переполнения указателя стека. Если стек создается с использование м такой защиты, реализация выделяет дополнительную па м ять в конце области переполнения стека, которая служит специальным буфером. Если приложение переполняет стек, входя в этот буфер, формируется сигнал ошибки (возможно, в сигнале SIGSEGV, передаваемом потоку).

Реализация может округлить значение, содержащееся в атрибуте guardsize, до числа, кратного значению реконфигурируемой системной переменной {PAGESIZE} (см. заголовок <sys/mman.h>). Если реализация округлит значение атрибута guardsize до числа, кратного значению пере м енной {PAGESIZE}, то при вызове функции pthread_attr_getguardsize () с заданным параметром attr в пара м етре guardsize сохранится размер защитной области, установленный в результате предварительного вызова функции pthread_attr_setguardsize ().

По у м олчанию значение атрибута guardsize равно {PAGESIZE} байтам. Реальное значение пере м енной {PAGESIZE} определяется реализацией.

Если предварительно был установлен атрибут stackaddr или stack (т.е. инициатор вызова са м остоятельно выделяет па м ять для стеков потока и управляет этой па м ятью), то атрибут guardsize игнорируется, и никакая защита от переполнения стека потока реализацией не обеспечивается. Вся ответственность в этом случае за управление памятью стека лежит на приложении.

Возвращаемые значения

При успешно м завершении функции pthread_attr_getguardsize() и pthread_attr_setguardsize() возвращают нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_attr_getguardsize () завершится неудачно, если:

[EINVAL ] значение, заданное пара м етро м guardsi ze, недействительно;

[ EINVAL ] значение пара м етра аttr недействительно.

Эти функции не возвращают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствует.

Логическое обоснование

Атрибут guardsize предла г ается для испо л ьзования при л ожение м по дву м причина м.

1. На защиту от переполнения могут потенциально затрачиваться существенные системные ресурсы. Для приложения, в котором создается большое количество потоков и существует уверенность в том, что при выполнении потоков их стеки никогда не будут переполнены, можно сэкономить системные ресурсы, отключив выделение областей защиты.

2. Если потоки размещают в стеке большие структуры данных, то для обнаружения факта переполнения стека могут понадобиться области защиты большого объема.

Будущие направления

Отсутствуют.

Смотри также

То м Base Definitions стандарта IEEE Std 1003.1-2001.

<pthread.h> , <sys/mman.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5.

Issue 6

Из раздела «Ошибки» было удалено третье условие возникновения ошибки [EINVAL] , поскольку оно включается во второе условие.

В целях согласования со стандарто м ISO/IEC 9899: 1999 в прототип функции pthread_attr_getguardsize () было добавлено ключевое слово restrict.

pthread_attr_getinheritsched, pthread_attr_setinheritsched

Имя

pthread_attr_getinheritsched, pthread_attr_setinheritsched— функции считывания и установки атрибута inheritsched (REALTIME THREADS).

Синопсис

THRTPS #include <pthread.h>

int pthread_attr_getinheritsched (

const pthread_attr_t *restrict attr, int *restrict inheritsched);

int pthread_attr_setinheritsched (pthread_attr_t *attr,

int inheritsched);

Описание

Функции pthread_attr_getinheritsched() и pthread_attr_setinheritsched() используются для считывания и установки соответственно атрибута inheri tsched в объекте, заданно м пара м етро м аttr.

Если при вызове функции pthread_create () используются объекты атрибутов, то атрибут inheritsched определяет, как будут устанавливаться другие атрибуты планирования создавае м ого потока.

Значение PTHREAD_INHERIT_SCHED говорит о то м, что атрибуты планирования потоков наследуются от создающего потока, а атрибуты планирования, содержащиеся в объекте, заданно м пара м етро м attr, игнорируются.

Значение PTHREAD_EXPLICIT_SCHED подразу м евает, что атрибуты планирования потоков устанавливаются равны м и соответствующи м значения м, содержащи м ся в объекте атрибутов, заданно м пара м етро м attr.

Значения PTHREAD_INHERIT_SCHED и PTHREAD_EXPLICIT_SCHED определяются в заголовке <pthread. h>.

От значения атрибута inheritsched зависят следующие атрибуты планирования потоков, определенные стандарто м IEEE Std ЮОЗ.1-2001: стратегия планирования (schedpolicy), пара м етры планирования (schedparam) и область конкуренции (contentionscope).

Возвращаемые значения

При успешно м завершении функции pthread_attr_getinheritsched() Hpthread_attr_setinheritsched() возвращают нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_attr_setinheritsched () м ожет завершиться неудачно, если:

[EINVAL]  значение, заданное пара м етро м inheri tsched, недействительно;

[ENOTSUP] была сделана попытка установить атрибут равны м значению, которое не поддерживается реализацией.

Эти функции не возвра щ ают код ошибки [ EINTR].

Примеры

Отсутствуют.

Замечания по использованию

После установки этих атрибутов поток м ожно создать путе м вызова функции pthread_create () с заданны м и атрибута м и. Использование этих функций не оказывает влияния на поток, выполняе м ый в данный м о м ент.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_attr_destroy (), pthread_attr_getscope (), pthread_attr_getschedpolicy(), pthread_attr_getschedparam(), pthread_create (), то м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>, <sched.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширение м POSIX Threads Extension.

От м ечены как часть группы Realtime Threads Feature Group.

Issue 6

Функции pthread_attr_getinheritsched() и pthread_attr_setinheritsched () от м ечены как часть опций Threads и Thread Execution Scheduling.

Условие ошибки [ENOSYS] было удалено,поскольку в заглушках нет необходимости, если реализация не поддерживает опцию Thread Execution Scheduling.

В целях согласования со стандартом ISO/IEC 9899: 1999 в прототип функции pthread_attr_getinheritsched () было добавлено ключевое слово restrict.

pthread_attr_getschedparam, pthread_attr_setschedparam

Имя

pthread_attr_getschedparam, pthread_attr_setschedparam— функции считывания и установки атрибута schedparam.

Синопсис

THR #include <pthread.h>

int pthread_attr_getschedparam (const pthread_attr_t *restrict attr, struct sched_param *restrict param);

int pthread_attr_setschedparam (pthread_attr_t *restrict attr,const struct sched_param *restrict param);

Описание

Функции pthread_attr_getschedparam() и pthread_attr_setschedparam() используются для считывания и установки соответственно атрибутов параметров планирования в объекте, заданном параметром attr. Содержимое структуры param определено в заголовке <sched.h>. Для установки стратегий планирования SCHED_FIFO и SCHED_RR единственным обязательным членом структуры param является sched_priority.

TSP Для установки стратегии планирования SCHED_SPORADIC необходимо установить следующие члены структуры param: sched_priority, sched_ss_low_priority, sched_ss_repl_period, sched_ss_ini t_budget и sched_ss_max_repl. Для успешного выполнения функции установки необходи м о, чтобы заданное значение члена sched_ss_repl_period было больше или равно значению заданного члена sched_ss_init _ budget; в противно м случае функция завершится неудачно. Для успешного выполнения функции установки также необходи м о, чтобы значение члена sched_ss_max_repl находилось в пределах включающего диапазона [1.{SS_REPL_MAX}]; в противном случае функция завершится неудачно.

Возвращаемые значения

При успешном завершении функции pthread_attr_getschedparam() и pthread_attr_setschedparam() возвращают нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_attr_setschedparam () м ожет завершиться неудачно, если:

[EINVAL]  значение, заданное пара м етро м param, недействительно;

[ ENOTSUP ] была сделана попытка установить атрибут равны м значению, которое не под д ерживается реализацией.

Эти функции не возвращают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

После установки этих атрибутов поток м ожно создать путе м вызова функции pthread_create () с использование м объекта атрибутов. Применение этих функций не оказывает влияния на поток, выполняемый в данный момент.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_attr_destroy(), pthread_attr_getscope(), pthread_attr_getinheritsched(), pthread_attr_getschedpolicy(), pthread_create (), то м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>, <sched.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширение м POSIX Threads Extension.

Отмечены как часть группы Realtime Threads Feature Group.

Issue 6

Функции pthread_attr_getschedparam () и pthread_attr_setschedparam () отмечены как часть опции Threads.

В целях согласования со стандарто м IEEE Std 1003.1d-1999 была добавлена стратегия планирования SCHED_SPORADIC.

В целях согласования со стандарто м ISO/IEC 9899: 1999 в прототипы функций pthread_attr_getschedparam() и pthread_attr_setschedparam() было добавлено ключевое слово restrict.

pthread_attr_getschedpolicy, pthread_attr_setschedpolicy

Имя

pthread_attr_getschedpolicy, pthread_attr_setschedpolicy — функции считывания и установки атрибута schedpolicy (REALTIME THREADS).

Синопсис

THR, TPS

#include <pthread.h>

int pthread_attr_getschedpolicy (const pthread_attr_t *restrict attr, int *restrict policy) ;

int pthread_attr_setschedpolicy (pthread_attr_t *attr, int policy) ;

Описание

Функции pthread_attr_getschedpolicy () и pthread_attr_setschedpolicy () используются для считывания и установки соответственно атрибута schedpolicy в объекте атрибутов, адресуемом параметром аttr.

Для обозначения стратегии планирования поддерживаются значения SCHED_FIF0, SCHED_RR и SCHED_OTHER, которые определены в заголовке <sched. h>.

TSP Когда потоки, выполняющиеся с использованием стратегий планирования SCHED_FIFO, SCHED_RR или SCHED_SPORADIC, ожидают освобождения мьютекса, то его получение (после разблокировки) происходит согласно приоритета м.

Возвращаемые значения

При успешном завершении функции pthread_attr_getschedpolicy() и pthread_attr_setschedpolicy() возвращают нулевое значение; в противно м случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_attr_setschedpolicy () м ожет завершиться неудачно, если:

[EINVAL] значение, заданное пара м етро м policy, недействительно;

[ENOTSUP] была сделана попытка установить атрибут равным значению, которое не поддерживается реализацией.

Эти функции не возвращают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

После установки этих атрибутов поток можно создать путем вызова функции pthread_create () с использованием объекта атрибутов. Применение этих функций не оказывает влияния на поток, выполняемый в данный момент.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_attr_destroy(), pthread_attr_getscope(), pthread_attr_getinheritsched (), pthread_attr_getschedparam(), pthread_create (), том Base Definidons стан д арта IEEE Std 1003.1-2001, <pthread.h>, <sched.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширение м POSIX Threads Extension.

От м ечены как часть группы Realtime Threads Feature Group.

Issue 6

Функции pthread_attr_getschedpolicy() и pthread_attr_setschedpolicy () от м ечены как часть опций Threads и Thread Execution Scheduling.

Условие ошибки [ENOSYS] было удалено, поскольку в заглушках нет необходимости, если реализация не поддерживает опцию Thread Execution Scheduling.

В целях согласования со стандарто м IEEE Std 1003.1d-1999 была добавлена стратегия планирования SCHED_SPORADIC.

В целях согласования со стандарто м ISO/IEC 9899: 1999 в прототип функции pthread_attr_getschedpolicy () было добавлено ключевое слово restrict.

pthread_cancel

Имя

pthread_cancel — функция от м ены выполнения потока.

Синопсис

THR #include <pthread.h>

int pthread_cancel (pthread_t thread);

Описание

Функция pthread_cancel () создает запрос на отмену потока. Когда именно отмена вступит в силу, зависит от текущего состояния потока, заданного параметром thread, и его типа. При от м ене потока должны быть вызваны обработчики, выполняющие подготовительные действия, связанные с отменой потока. По завершении последнего обработчика должны быть вызваны деструкторы объектных данных, используемых отменяемым потоком. По завершении последнего деструктора поток, заданный пара м етро м thread, должен завершиться.

Действия, связанные с от м еной заданного потока, выполняются асинхронно по отношению к потоку, вызывающему функцию pthread_cancel ().

Возвращаемое значение

При успешном завершении функция pthread_cancel () возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_cancel () м ожет завершиться неудачно, если:

[ESRCH] не удалось найти поток, иде н тификационный но м ер (ID) которого соответствовал бы заданно м у.

Функция pthread_cancel () не возвра щ ает код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Для отправки потоку уведо м ления об от м ене расс м атривалось два альтернативных варианта. Для одного предполагалось определить новый сигнал SIGCANCEL с соответствующей семантикой отмены, а для другого— новую функцию pthread_cancel (), которая бы приводила в действие процедуру отмены потока.

Преимущество варианта, прелусматривающего создание нового сигнала, состояло в том, что критерии его выдачи были бы во многом идентичны тем, которые использовались при попытке выдать любой другой сигнал, поэтому сигнальный механизм уведомления об отмене казался унифицированным. И в самом деле, во многих реализациях отмена потоков осуществляется посредством специального сигнала. Однако до сих пор не существовало ни одной сигнальной функции (за исключением функции pthread_kill()), которую можно было бы использовать совместно с этим новым сигналом, поскольку поведение выдаваемого сигнала отмены должно было отличаться от поведения любого из уже определенных сигналов.

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

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

Будущие направления

Отсутствуют.

Смотри также

pthread_exit (), pthread_cond_timedwait (), pthread_join (), pthread_setcancelstate (), то м Base D e finitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функция впервые реализована в выпуске Issue 5. Включена для согласования с расширение м POSIX Threads Ext e nsion.

Issue 6

Функция pthread_cancel () от м ечена как часть опции Thr e ads.

pthread_cleanup_pop, pthread_cleanup_push

Имя

pthread_cleanup_pop, pthread_cleanup_push— функции создания обработчиков запроса об от м ене потоков.

Синопсис

THR

#include <pthread.h>

void pthread_cleanup_pop (int execute);

void pthread_cleanup_push (void (* routine) (void*),void *arg);

Описание

Функция pthread_cleanup_pop () используется для извлечения функции, расположенной в вершине стека вызываю щ его потока, предназначенного дл я выполнения подготовительных действий по аннулированию потока, и ее вызова (если пара м етр execute не равен нулю).

Функция pthread_cleanup_push() позволяет поместить в стек вызывающего потока заданную функцию обработчика routine, предназначенного для выполнения подготовительных действий по аннулированию потока. Этот обработчик будет извлечен из соответствующего стека и вызван с аргументом arg при наличии следующих условий:

• поток существует (т.е. он вызывает функцию pthread_exit ());

• поток действует в соответствии с запросом отмены;

• поток вызывает функцию pthread_cleanup_pop() с ненулевым значением аргумента execute.

Эти функции можно реализовать как макросы. Приложение должно гарантировать, что они имеют форму инструкций и используются попарно в пределах одного и того же лексического контекста (чтобы макрос pthread_cleanup_push () раскрывался в список лексем, начинающийся лексемой '{', а макрос pthread_cleanup_pop() раскрывался в список лексем, завершающийся соответствующей лексемой '}').

Результат вызова функции longjmp() или siglongjmp() не определен, ec-ли имели место обращения к функции pthread_cleanup_push() или pthread_cleanup_pop() без соответствующего «парного» вызова по причине заполнения буфера переходов. Результат вызова функции longjmp () или siglongjmp() из обработчика, предназначенного для выполнения подготовительных действий по аннулированию потока, также не определен.

Возвращаемые значения

Функции pthread_cleanup_push() и hread_cleanup_pop() не возвра щ ают никакого значения.

Ошибки

Ошибки не определены.

Эти функции не возвращают код ошибки [EINTR].

Примеры

Следующий код представляет собой пример использования примитивов потока для реализации блокировки чтения-записи (с приоритетом для записи) с возможностью отмены.

typedef struct {

pthread_mutex_t lock; pthread_cond_t rcond, wcond;

int lock_count;

/* lock_count < 0 .. Удерживается записывающим потоком. */ /* lock_count > 0 .. Удерживается lock_count считывающими * потоками. */

/* lock_count = 0 .. Ничем не удерживается. */ int waiting_writers; /* Счетчик ожидающих записывающих

* потоков. */

} rwlock;

void

waiting_reader_cleanup (void, *arg) {

rwlock *1;

1 = (rwlock *) arg;

pthread_mutex_unlock (&l->lock);

}

void

lock_for_read (rwlock *1) {

pthread_mutex_lock (&l->lock);

pthread_cleanup_push (waiting_reader_cleanup, 1) ;

while ((l->lock_count < 0) && (l->waiting_writers ! = 0))

pthread_cond_wait (&l->rcond, &l->lock);

l->lock_count++;

/*

* Обратите внимание на то, что функция pthread_cleanup_pop()

* выполняет здесь фyнкциюwaiting_reader_cleanup(). */

pthread_cleanup_pop(l); }

void

release_read_lock (rwlock *1) {

pthread_mutex_lock (&l->lock); if (--l->lock_count == 0) pthread_cond_signal (&l->wcond); pthread_mutex_unlock (1);

void

waiting_writer_cleanup (void *arg) {

rwlock *1;

1 = (rwlock *) arg;

if ((—l->waiting_writers == О) && (l->lock_count >= 0)) { /*

* Это происходит только в случае отмены потока. */

pthread_cond_broadcast (&l->wcond);

}

pthread_mutex_unlock (&l->lock);

}

void

lock_for_write (rwlock *1) {

pthread_mutex_lock (&l->lock),-l->waiting_writers++;

pthread_cleanup_push (waiting_writer_cleanup, 1); while (l->lock_count ! = О) pthread_cond_wait (&l->wcond, &l->lock); l->lock_count = -1; /*

* Обратите внимание на то, что функция pthread_cleanup_pop()

* выполняет здесь функцию waiting_writer_cleanup(). */

pthread_cleanup_pop (1);

}

void

release_write_lock (rwlock *1) {

pthread_mutex_lock (&l->lock);

l->lock_count = 0;

if (l->waiting_writers == О)

pthread_cond_broadcast (&l->rcond)

else

pthread_cond_signal (&l->wcond); pthread_mutex_unlock (&l->lock);

}

/*

* Эта функция вызывается для инициализации блокировки

* чтения-записи. */

void

initialize_rwlock (rwlock *1) {

pthread_mutex_init (&l->lock, pthread_mutexattr_default); pthread_cond_init (&l->wcond, pthread_condattr_default); pthread_cond_init (&l->rcond, pthread_condattr_default); l->lock_count = О; l->waiting_writers = О;

\

Приложение Б 559

}

reader_thread() {

lock_for_read (&lock);

pthread_cleanup_push (release_read_lock, &lock); /*

* Поток устанавливает блокировку для чтения. */

pthread_cleanup_pop (1);

}

writer_thread() {

lock_for_write (&lock);

pthread_cleanup_push (release_write_lock, &lock); /*

* Поток устанавливает блокировку для записи. */

pthread_cleanup_pop (1) ;

}

Замечания по использованию

Две описываемые здесь функции, pthread_cleanup_push() и pthread_cleanup_pop (), которые помещают и извлекают из стека обработчики запроса на отмену потока, можно сравнить с левой и правой круглыми скобками. Их нужно всегда использовать «в паре».

Логическое обоснование

Ограничение, налагае м ое на две функции, pthread_cleanup_push() и pthread_cleanup_pop(), которые помещают и извлекают из стека обработчики запроса на отмену потока, и состоящее в том, что они должны использоваться попарно в пределах одного и того же лексического контекста, позволяет создавать эффективные макросы (или компиляторные реализации) и эффективно управлять памятью. Вариант реализации этих функций в виде макросов может выглядеть следующим образом,

#define pthread_cleanup_push (rtn, arg) { \

struct _pthread_handler_rec _cleanup_handler, **_head; \

_cleanup_handler.rtn = rtn; \

_cleanup_handler.arg = arg; \

(void) pthread_getspecific (_pthread_handler_key, &_head);

\

_cleanup_handler.next = *_head; \

*_head = &_cleanup_handler;

#define pthread_cleanup_pop (ex) \

*_head = _cleanup_handler.next; \

if (ex) (*_cleanup_handler.rtn) (_cleanup_handler.arg); \

}

Возможна даже более «смелая» реализация этих функций, которая позволит компилятору «считать» обработчик запроса на отмену константой, значение которой можно «встраивать» в код. В данном томе стандарта IEEE Std 1003.1-2001 пока оставлен неопределенным результат вызова функции longjmp () из обработчика сигнала, выполняемого в функции библиотеки POSIX System Interfaces. Если в какой-то реализации потребуется разрешить этот вызов и придать ему надлежащее поведение, функция longjmp () должна в этом случае вызвать все обработчики запроса на отмену, которые были помещены в стек (но еще не извлечены из него) с момента вызова функции setjmp ().

Рассмотрим многопоточную функцию, вызываемую одним потоком, который использует сигналы. Если бы сигнал был выдан обработчику сигналов во время операции qsort(), и этому обработчику пришлось бы вызвать функцию longjmp() (которая в свою очередь не вызывала бы обработчики запроса на отмену), то вспомогательные потоки, создаваемые функцией qsort (), не были бы аннулированы. Они бы продолжали выполняться и осуществляли запись в массив аргументов даже в том случае, если этот массив был к тому времени извлечен из стека.

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

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

Будущие направления

Отсутствуют.

Смотри также

pthread_cancel(), pthread_setcancelstate(), то м Base Definitions стандарта IEEEStd ЮОЗ.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширение м POSIX Threads Extension.

Issue 6

Функции pthread_cleanup_pop() и pthread_cleanup_push() от м ечены как часть опции Threads.

Добавлен раздел «За м ечания по использованию» (APPLICATION USAGE).

Раздел «Описание» был отредактирован с целью исключить из него слово « must» («должен»).

pthread_cond_broadcast(),pthread_cond_signal()

Имя

pthread_cond_broadcast(),pthread_cond_signal()

Описание

Эти функции используются для разблокировки потоков, заблокированных с помощью переменной условия.

Функция pthread_cond_broadcast () позволяет разблокировать все потоки, заблокированные в данный момент с использованием переменной условия, заданной параметром cond.

Функция pthread_cond_signal () используется для разблокировки по крайней мере одного из потоков, заблокированных с использованием условной переменной, заданной параметром cond (если таковые существуют). Если с использованием этой переменной условия заблокировано несколько потоков, то порядок разблокировки будет определен в соответствии с их стратегией планирования. Когда каждый поток, разблокированный в результате вызова функции pthread_cond_broadcast () или pthread_cond_signal(), вернется из вызванной им функции pthread_cond_wait () или pthread_cond_timedwait(), этот поток получит мьютекс, с которым была вызвана функция pthread_cond_wait() или pthread_cond_timedwait(). Разблокированные потоки будут состязаться за мьютекс в соответствии с их стратегией планирования (если это имеет смысл), как будто каждый из них вызвал функцию pthread_mutex_lock ().

Функции pthread_cond_broadcast () и pthread_cond_signal () могут быть вызваны потоком, владеющим (или нет) в данный момент мьютексом. При этом потоки, вызвавшие функцию pthread_cond_wait () или pthread_cond_timedwait (), связали во время ожидания этот мьютекс с условной переменной. Однако, если необходимо обеспечить прогнозируемое поведение, этот мьютекс может быть заблокирован потоком, вызвавшим функцию pthread_cond_broadcast () или pthread_cond_signal ().

Функции pthread_cond_broadcast() и pthread_cond_signal() не будут иметь результата, если в данный момент не су щ ествует потоков, заблокированных с использованием условной переменной, за д анной параметром cond.

Возвращаемые значения

При успешном завершении функции pthread_cond_broadcast () и pthread_ cond_signal () возвра щ ают нулевое значение; в противном случае — ко д ошибки, обозначаю щ ий ее характер.

pthread_cond_broadcast, pthread_cond_signal — функции разблокировки потоков, заблокированных с по м о щ ью пере м енной условия.

Синопсис

THR

#include <pthread.h>

int pthread_cond_broadcast (pthread_cond_t *cond);

int pthread_cond_signal (pthread_cond_t *cond);

|Ошибки

Функции pthread_cond_broadcast () и pthread_cond_signal () м огут завершиться неудачно, если:

[EINVALJ значение, заданное параметром cond, не ссылается на инициализированную условную переменную.

Эти функции не возвращают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

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

Функцию pthread_cond_signal () небезопасно использовать в обработчике сигналов, который вызывается асинхронно. Даже если это было бы безопасно, имела бы место «гонка» данных между проверками булевой функции pthread_cond_ wait (), которую невозможно эффективно устранить.

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

Логическое обоснование

Несколько запусков по условному сигналу

Для мультипроцессора, скорее всего, невозможно применить функцию pthread_cond_signal(), чтобы избежать разблокировки нескольких потоков, заблокированных с использованием условной переменной. Рассмотрим, например, следующую частичную реализацию функций pthread_cond_wait () и pthread_cond_ signal(), выполняемых потоками в заданном порядке. Один поток пытается «дождаться» нужного значения условной переменной, другой при этом выполняет функцию pthread_cond_signal(), в то время как третий поток уже находится в состоянии ожидания.

pthread_cond_wait(mutex, cond):

value = cond->value; /* 1 */

pthread_mutex_unlock (mutex); /* 2 */

pthread_mutex_lock (cond->mutex); /* 10 */

if (value == cond->value) { /* 11 */

me->next_cond = cond->waiter;

cond->waiter = me;

pthread_mutex_unlock(cond->mutex);

unable_to_run (me);

} else

pthread_mutex_unlock (cond->mutex); /* 12 */

pthread_mutex_lock (mutex); /* 13 * /

pthread_cond_signal (cond):

pthread_mutex_lock (cond->mutex); /* 3 */

cond->value++; /* 4 */

if (cond->waiter) { /* 5 */

sleeper = cond->waiter; /* 6 */

cond->waiter = sleeper->next_cond; /* 7 */

able_to_run (sleeper); /* 8 */

}

pthread_mutex_unlock (cond->mutex); /* 9 */

Итак, в результате одного обращения к функции pthread_cond_signal () сразу несколько потоков могут вернуться из вызова функции pthread_cond_wait () или pthread_cond_timedwait (). Такой эффект называется «фиктивным запуском». Обратите внимание на то, что подобная ситуация является самокорректирующейся благодаря тому, что количество потоков, «пробуждающихся» таким путем, ограничено; например, следующий поток, который вызывает функцию pthread_cond_wait (), после определенной последовательности событий блокируется.

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

В разрешении «фиктивных запусков» есть одно дополнительное преимущество: знал о них, разработчикам приложений придется прелусмотреть цикл тестирования предиката при ожидании наступления нужного условия. Это также вынудит приложение «терпеливо» отнестись к распространению «лишних» условных сигналов, связанных с одной и той же условной переменной, формирование которых может быть закодировано в какой-то другой части приложения. В результате приложения станут более устойчивыми. Поэтому в стандарте IEEE Std 1003.1-2001 в прямой форме отмечена возможность возникновения «фиктивных запусков».

Будущие направления

Отсутствуют.

Смотри также

pthread_cond_destroy (), pthread_cond_timedwait (), том Base Definitions cтaндapтa IEEEStd 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширение м POSIX Threads Extension.

Issue 6

Функции pthread_cond_broadcast() и pthread_cond_signal() от м ечены как часть опции Threads.

Добавлен раздел «Замечания по использованию» (APPLICATION USAGE).

pthread_cond_destroy, pthread_cond_init

Имя

pthread_cond_destroy, pthread_cond_init

Синопсис

THR

#include <pthread.h>

int pthread_cond_destroy (pthread_cond_t *cond);

int pthread_cond_init (

pthread_cond_t *restrict cond,

const pthread_condattr_t *restrict attr);

pthread_cond_t cond = PTHREAD_COND_INITIALIZER;

Описание

Функция pthread_cond_destroy () используется для разрушения условной пере м енной, заданной пара м етро м cond, в результате чего объект становится неинициализированны м. В конкретной реализации функция pthread_cond_destroy () м ожет устанавливать объект, адресуемый параметром cond, равны м недействительно м у значению. Разрушенный объект условной пере м енной м ожно снова инициализировать с по м ощью функции pthread_cond_init (); результаты ссылки на этот объект после его разрушения не определены.

Нет никакой опасности в разрушении инициализированной условной переменной, по которой не заблокирован в данный момент ни один поток. Попытка же разрушить условную переменную, по которой заблокированы в данный момент другие потоки, может привести к неопределенному поведению.

Функция pthread_cond_init() используется для инициализации условной пере м енной, адресуе м ой пара м етро м cond, объекто м атрибутов, адресуе м ы м пара м етро м attr. Если пара м етр attr со д ержит значение NULL, для инициализации применяются атрибуты условной переменной, действующие по умолчанию, т.е. результат в этом случае равносилен передаче адреса объекта, содержащего стандартные атрибуты условной пере м енной. После успешной инициализации Условная Переменная становится инициализированной.

Для осуществления синхронизации используется только сама условная переменная cond. Результат ссылки на копии пере м енной cond в обращениях к функциям pthread_cond_wait(), pthread_cond_timedwait(), pthread_cond_signal(), pthread_cond_broadcast() и pthread_cond_destroy() неопределен. Попытка инициализировать уже инициализированную условную переменную приведет к неопределенному поведению.

Если атрибуты условной переменной, действующие по умолчанию, заранее определены, для инициализации условных переменных, которые создаются статически, можно использовать макрос PTHREAD_COND_INITIALIZER. Результат в это м случае эквивалентен дина м ической инициализации путе м вызова функции pthread_cond_init () с пара м етро м attr, равны м значению NULL, но без проверки на наличие ошибок.

Возвращаемые значения

При успешно м завершении функции pthread_cond_destroy() и pthread_cond_init() возвращают нулевое значение; в противно м случае— код ошибки, обозначающий ее характер.

Проверка на наличие ошибок с кодами [EBUSY] и [EINVAL] реализована так (если реализована вообще), как будто она выполняется в самом начале работы каждой функции, и код ошибки в случае ее обнаружения возвращается до модификации состояния условной переменной, заданной параметром cond.

Ошибки

Функция pthread_cond_destroy () может завершиться неудачно, если:

[EBUSY] реализация обнаружила попытку разрушить объект, адресуемый параметром cond, который относится к другому потоку (например, при использовании в функциях pthread_cond_wait() или pthread_cond_timedwait ());

[EINVAL] значение, заданное пара м етро м cond, недействительно.

Функция pthread_cond_init () завершится неудачно, если:

[EAGAIN] система испытывает недостаток в ресурсах (не имеется в виду память), необходимых для инициализации еще одной условной переменной;

[ENOMEM] для инициализации условной переменной недостаточно существующей памяти.

Функция pthread_cond_init () может завершиться неудачно, если:

[EBUSY] реализация обнаружила попытку повторно инициализировать объект условной переменной, адресуемый параметром cond, которой был ранее инициализирован, но еще не разрушен;

[ EINVAL ] значение, заданное параметром аttr, недействительно.

Примеры

Условную пере м енную м ожно разрушить сразу после того, как будут запущены все потоки, заблокированные по ней. Рассмотрим, например, следующий код.

struct list {

pthread_mutex_t lm;

}

struct elt {

key k;

int busy;

pthread_cond_t notbusy;

}

/* Находим элемент списка и сохраняем его. */

struct elt * list_find (struct list *lp, key k) {

struct elt *ep;

pthread_mutex_lock (&lp->lm);

while ((ep = find_elt (1, к) ! = NULL) && ep->busy)

pthread_cond_wait (&ep->notbusy, &lp->lm);

if (ер != NULL) ep->busy = 1;

pthread_mutex_unlock (&lp->lm) ;

return (ер);

}

delete_elt (struct list *lp, struct elt *ep) {

pthread_mutex_lock (&lp->lm);

assert (ep->busy);

//... удаляем элемент ер из списка …

ep->busy = 0; /* Paranoid. */

(A) pthread_cond_broadcast (&ep->notbusy);

pthread_mutex_unlock (&lp->lm);

(B) pthread_cond_destroy (&rp->notbusy);

free (ер);

}

В этом примере условную переменную и ее элемент списка можно освободить (строка В) сразу после того, как все потоки, ожидающие соответствующего значения условной переменной, будут «разбужены» (строка А), поскольку мьютекс и этот код гарантируют, что никакой другой поток не сможет ссылаться на удаляемый элемент.

Замечания по использованию

Отсутствуют.

Логическое обоснование

С м. раздел «Логическое обоснование» в описании функции pthread_mutex_init ().

Будущие направления

Отсутствуют.

Смотри также

pthread_cond_broadcast (), pthread_cond_signal (), pthread_cond_timedwait (), то м Base Definidons стандартаШЕЕStd 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширение м POSIX Threads Extension.

Issue 6

Функции pthread_cond_destroy() и pthread_cond_init() от м ече н ы как часть опции Threads.

Раздел «Описание» был отредактирован путе м при м енения интерпретации IEEE PASC Interpretation 1003.1с #34.

В целях согласования со стандарто м ISO/IEC 9899:1999 в прототип функции pthread_cond_init () было добавлено ключевое слово restrict.

pthread_cond_timedwait, pthread_cond_wait

Имя

pthread_cond_timedwait, pthread_cond_wait — функции ожидания условия.

Синопсис

THR

#include <pthread.h>

int pthread_cond_timedwait ( pthread_cond_t *restrict cond, pthread_mutex_t *restrict mutex, const struct timespec *restrict abstime);

int pthread_cond_wait (pthread_cond_t *restrict cond, pthread_mutex_t *restrict mutex);

Описание

Функции pthread_cond_timedwait() и pthread_cond_wait() используются для блокирования потоков по условной переменной. Они вызываются с использованием мьютекса mutex , блокируемого вызывающим потоком; в противном случае результирующее поведение не определено.

Эти функции автоматически освобождают мьютекс mutex и обеспечивают блокирование вызывающего потока по условной переменной cond; «автоматически» здесь означает «автоматический доступ к мьютексу со стороны другого потока с последующим доступом к условной переменной». Другими словами, если какой-то другой поток может получить мьютекс после его освобождения вызывающим потоком, то результат последующего вызова функции pthread_cond_broadcast () или pthread_cond_signal () в этом (другом) потоке будет таким, как если бы он имел место после блокирования вызывающего потока.

При успешном выполнении мьютекс будет заблокирован, а владеть им будет вызывающий поток.

При использовании условных переменных всегда существует булев предикат, совместно используемый этими переменными, которые связаны с каждым ожидаемым условием. Это условие становится истинным, если поток должен продолжать выполнение. При использовании функций pthread_cond_timedwait() или pthread_cond_wait () возможны фиктивные запуски. Поскольку возврат из этих функций не подразумевает ничего, кроме оценки значения упомянутого выше предиката, он должен вычисляться после каждого такого выхода из функции.

Результат использования нескольких мьютексов для параллельно выполняемых операций pthread_cond_timedwait () или pthread_cond_wait () по одной и той же условной переменной не определен; другими словами, условная переменная связывается с уникальным мьютексом, когда поток ожидает заданного значения условной переменной, и это (динамическое) связывание завершится вместе с завершением ожидания.

Ожидание условия (синхронизированное или нет) представляет собой «точку отмены». Если статус возможности аннулирования дл я потока соответствует значению PTHREAD_CANCEL_DEFERRED, побочным эффектом действий, выполняемых по запросу на аннулирование во время ожидания условия будет повторный захват мьютекса перед вызовом первого обработчика запроса на отмену. Другими словами, результат будет выглядеть так, как если бы поток был разблокирован и получил воз м ожность выполниться до точки выхода из вызова функции pthread_cond_timedwait() или pthread_cond_wait(), но в этой точке «обнаружил» запрос на от м ену и в м есто возврата к инициатору вызова функции pthread_cond_timedwait() или pthread_cond_wait() приступил к выполнению действий по аннулированию, которые включают вызов обработчиков этого запроса.

Поток, который был разблокирован по причине отмены в то время, пока он был заблокирован в вызове функции pthread_cond_timedwait() или pthread_cond_wait (), не будет использовать условный сигнал, который можно направить параллельно на условную переменную, если существуют другие потоки, заблокированные по этой условной переменной.

Функция pthread_cond_timedwait() эквивалентна функции pthread_cond_wait (), за исключением того, что она возвращает код ошибки, если абсолютное время, заданное пара м етро м abstime, наступит (т.е. системное время станет равным или превысит значение abstime) до того, как будет передано (с помощью сигнала) условие cond, или если абсолютное время, заданное параметром abstime, уже наступило в момент вызова.

C S Если поддерживается опция Clock Selection, условная переменная будет иметь атрибут часов, определяющий механизм, который предназначен для измерения времени, заданного параметром abstime . По истечении заданного времени функция pthread_cond_timedwait() освободит и снова захватит мьютекс, адресуемый параметром mutex . Функция pthread_cond_timedwait () также представляет собой точку отмены.

Если потоку, ожидающему значения условной переменной, передается сигнал, то при возврате из обработчика сигнала поток возобновит ожидание этой условной переменной (как будто не было никакого прерывания на обработку сигнала) или возвратит нуль вследствие фиктивного запуска.

Возвращаемые значения

За исключением кода ошибки [ETIMEDOUT], все проверки на наличие ошибок реализованы так, как если бы они были выполнены в самом начале работы каждой функции, и код ошибки в случае ее обнаружения возвращается до модификации состояния мьютекса, заданного пара м етро м mutex, или условной переменной, заданной параметром cond.

При успешном завершении возвращается нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_cond_timedwait () завершится неудачно, если:

[ETIMEDOUT]  вре м я, заданное пара м етро м abstime, наступило.

Функции pthread_cond_timedwait() и pthread_cond_wait() м огут завершиться неудачно, если:

[EINVAL] значение, заданное хотя бы одни м из пара м етров cond, mutex или abstime, недействительно;

[EINVAL] для выполнения параллельных операций pthread_cond_timedwait() или pthread_cond_wait () по одной и той же условной пере м енной были задействованы различные мьютексы;

[EPERM]  во вре м я вызова любой из функций мьютексом не владел текущий поток.

Эти функции не возвращают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Семантика ожидания по условию

Важно от м етить, что, когда функции pthread_cond_wait() и pthread_cond_timedwait() завершаются без ошибки, соответствую щ ий предикат может все еще иметь ложное значение. Аналогично, когда функция pthread_cond_timedwait() возвращается с ошибкой истечения времени ожидания, соответствующий предикат может иметь истинное значение из-за неизбежной «гонки» между истечением периода ожидания и изменением состояния предиката.

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

В общем случае при каждом завершении ожидания по условию поток должен оценивать значение предиката, связанного с ожиданием по условию, чтобы узнать, может ли он безопасно продолжать выполнение, ожидать или объявить тайм-аут. Возврат из состояния ожидания не означает, что соответствующий предикат имеет конкретное значение (ЛОЖЬ или ИСТИНА).

Поэтому рекомендуется ожидание по условию выражать в коде, эквивалентно м циклу «while», который выполняет проверку предиката.

Семантика ожидания по времени

Абсолютное время было выбрано для задания параметра лимита времени по двум причинам. Во-первых, несмотря на то, что измерение относительного времени нетрудно реализовать в начале функции, для которой задается абсолютное время, с заданием абсолютного времени в начале функции, которая определяет относительное время, связано условие «гонок». Предположим, например, что функция clock_gettime() возвращает текущее время, а функция cond_relative_timed_wait () использует относительное время.

clock_gettime(CLOCK_REALTIME, &now)

reltime = sleep_til_this_absolute_time -now;

cond_relative_timed_wait (с, m, &reltime);

Если поток выгружается между первой и последней инструкциями, поток блокируется слишком надолго. Однако блокирование несущественно, если используется абсолютное время. Кроме того, абсолютное время не нужно пересчитывать, если оно используется в цикле несколько раз.

Для случаев, когда системные часы работают дискретно, можно предполагать, что реализации обработают любые ожидания по времени, истекающие в промежутке между дискретными состояниями, так, как если бы нужное время уже наступило.

Аннулирование потока и ожидание по условию

Ожидание по условию, синхронизированное или нет, является точкой отмены (аннулирования) потока. Другими словами, функции pthread_cond_wait () или pthread_cond_timedwait () представляют собой точки, в которых обнаружен необработанный запрос на отмену. Дело в том, что в этих точках возможно бесконечное ожидание, т.е. какое бы событие ни ожидалось, даже при совершенно корректной программе оно может никогда не произойти; например, входные данные, получения которых ожидает программа, могут быть никогда не отправлены. Сделав же ожидание по условию точкой отмены, поток можно безопасно аннулировать и выполнить соответствующие обработчики даже в случае, если программа «увязнет» в бесконечном ожидании.

Побочный эффект обработки запроса на от м ену потока в случае, когда он заблокирован по условной переменной, состоит в повторном захвате мьютекса до вызова любого из обработчиков. Это позволяет гарантировать, что обработчик запроса на отмену выполняется в таком же статусе, который имеет критический код, расположенный до и после вызова функции ожидания по условию. Это правило также требуется соблюдать при взаимодействии с POSIX -потоками, написанными на таких языках программирования, как Ada или С++, причем здесь можно организовать отмену потоков с использованием встроенного в язык механизма исключительных ситуаций. Это правило гарантирует, что каждый обработчик исключения, защищающий критический раздел, всегда может безопасно отталкиваться от следующего факта: связанный мьютекс уже заблокирован, независимо от того, в каком именно месте критического раздела было сгенерировано исключение. Без этого правила обработчики исключительных ситуаций не могли бы единообразно выполнять свою работу в отношении блокировки, и поэтому кодирование стало бы весьма громоздким.

Следовательно, поскольку в случае, когда запрос на отмену приходит во время ожидания, в отношении состояния блокировки должна быть выполнена определенная инструкция, при этом должно быть выбрано такое определение, которое сделает кодирование приложения наиболее удобным и свободным от ошибок.

При выполнении действий, связанных с получение м запроса на от м ену потока в то вре м я, когда он заблокирован по условной пере м енной, реализация требует гарантии, что поток не будет использовать ни один из условных сигналов, направленных на условную переменную, если существуют другие потоки, ожидающие сигнала по этой условной переменной. Соблюдение этого правила позволяет избежать условий взаимоблокировки, которые могут возникнуть в случае, если два независимых запроса (один действует в потоке, а другой связан с условной переменной) не были обработаны независимо.

Быстродействие мьютексов и условных переменных

Предполагается, что мьютексы должны блокироваться только для нескольких инструкций. Такая практика почти автоматически вытекает из желания программистов избегать длинных последовательностей программных инструкций (которые способны снизить общую эффективность параллелизма).

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

Из вышесказанного отнюдь не следует, что эффективность ожидания по условию не важна. Поскольку существует потребность по крайней мере в одном переключении контекста на рандеву (взаимодействие между параллельными процессами), то эффективность ожидания по условию также важна. Цена ожидания по условной переменной должна быть намного меньше минимальной цены одного переключения контекста и времени, затрачиваемого на разблокировку и блокировку мьютекса.

Особенности мьютексов и условных переменных

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

Планирование поведения мьютексов и условных переменных

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

Синхронизированное ожидание по условию

Функция pthread_cond_timedwait () позволяет приложению прервать ожидание наступления конкретного условия после истечения заданного интервала времени. Рассмотрим следующий пример.

(void) pthread_mutex_lock (&t. mn);

t.waiters++;

clock_gettime (CLOCK_REALTIME, &ts) ;

ts.tv_sec += 5;

rc = 0;

while (! mypredicate (&t) && rc == 0)

rc = pthread_cond_timedwait (&t.cond, &t.mn, &ts);

t.waiters--;

if (rc == 0) setmystate (&t);

(void) pthread_mutex_unlock (&t.mn);

Абсолютный параметр времени ожидания позволяет не пересчитывать его значение каждый раз, когда программа проверяет значение предиката блокирования. Если бы время ожидания было задано относительной величиной, соответствующий пересчет пришлось бы делать перед каждым вызовом функции. Это было бы особенно трудно сделать, поскольку такому колу пришлось бы учитывать возможность дополнительных запусков вследствие дополнительной сигнализации по условной переменной, которые могут происходить до того, как предикат станет истинным или истечет время ожидания.

Будущие направления

Отсутствуют.

Смотри также

pthread_cond_signal (), pthread_cond_broadcast (), том Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширением POSIX Threads Extension.

Issue 6

Функции pthread_cond_timedwait() и pthread_cond_wait() от м ечены как часть опции Threads.

К описанию прототипа функции pthread_cond_wait () был приложен список опечаток Open Group Corrigendum U021/9.

Для согласования со стандартом IEEE Std 1003.1j-2000 раздел «Описание» был отредактирован путем добавления семантики для опции Clock Selection.

В раздел «Ошибки» внесен еще один код ошибки [EPERM] в ответ на включение интерпретации IEEE PASC Interpretation 1003.1с #28.

В целях согласования со стандартом ISO/IEC 9899: 1999 в прототипы функций pthread_cond_timedwait() и pthread_cond_wait() было добавлено ключевое слово restrict.

pthread_condattr_destroy, pthread_condattr_init

Имя

pthread_condattr_destroy, pthread_condattr_init — функции разрушения и инициализации объекта атрибутов условной пере м енной.

Синопсис

THR

#include <pthread.h>

int pthread_condattr_destroy (pthread_condattr_t *attr);

int pthread_condattr_init (pthread_condattr_t *attr);

Описание

Функция pthread_condattr_destroy() используется для разрушения объекта атрибутов условной переменной, в результате чего он становится неинициализированным. В конкретной реализации функция pthread_condattr_destroy() может устанавливать объект, адресуемый параметром attr , равным недействительному значению. Разрушенный объект атрибутов attr можно снова инициализировать с помощью функции pthread_condattr_init (); результаты ссылки на этот объект после его разрушения не определены.

Функция pthread_condattr_init () предназначена для инициализации объекта атрибутов условной пере м енной attr значением, действующим по у м олчанию для всех атрибутов, определенных конкретной реализацией.

Если функция pthread_condattr_init () вызывается для уже инициализированного объекта атрибутов attr , то результаты вызова этой функции не определены.

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

Этот то м стан д арта IEEE Std 1003.1-2001 требует наличия д вух атрибутов: clock и process-shared.

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

Возвращаемые значения

При успешно м завершении функции pthread_condattr_destroy() Hpthread_condattr_init() возвращают нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_condattr_destroy () может завершиться неудачно, если:

[EINVAL]  значение, заданное параметром аttr, недействительно.

Функция pthread_condattr_init () завершится неудачно, если:

[ENOMEM]  для инициализации объекта атрибутов условной переменной недостаточно существующей памяти. Эти функции не возвращают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

С м. описание функций pthread_attr_init () и pthread_mutex_init (). Атрибут process-shared был определен для условных переменных по той же причине, что и для м ьютексов.

Будущие направления

Отсутствуют.

Смотри также

pthread_attr_destroy (), pthread_cond_destroy (), pthread_condattr_getpshared(), pthread_create(),

pthread_mutex_destroy (), то м Base Definitions стан д арта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширение м POSIX Threads Extension.

Issue 6

Функции pthread_condattr_destroy() и pthread_condattr_init() от м ечены как часть опции Threads.

pthread_condattr_getpshared, pthread_condattr_setpshared

Имя

pthread_condattr_getpshared, pthread_condattr_setpshared — функции считывания и установки атрибутаусловной пере м енной process-shared.

Синопсис

THR TSH

#include <pthread.h>

int pthread_condattr_getpshared (const pthread_condattr_t *restrict attr, int *restrict pshared);

int pthread_condattr_setpshared (pthread_conda 11 r_t * аttr, int pshared) ;

Описание

Функция pthread_condattr_getpshared () используется для получения значения атрибута process - shared из объекта атрибутов, адресуе м ого параметром attr. Функция pthread_condattr_setpshared() позволяет установить атрибут process-shared в инициализированно м объекте атрибутов, адресуе м о м пара м етро м attr .

Атрибут process-shared устанавливается равным значению PTHREAD_PROCESS_ SHARED, чтобы разрешить использование условной переменной любым потоком, имеющим доступ к области памяти, в которой она размещена, даже если эта область памяти разделяется несколькими процессами. Если же атрибут process-shared равен значению PTHREAD_PROCESS_PRIVATE , Условная Переменная должна использоваться только потоками, созданными в одном процессе с потоком, который ее инициализировал; если с этой условной переменной попытаются работать потоки из различных процессов, поведение такой программы не определено. По умолчанию для этого атрибута устанавливается значение PTHREAD_PROCESS_PRIVATE.

Возвращаемые значения

При успешном завершении функция pthread_condattr_setpshared() возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

При успешном завершении функция pthread_condattr_getpshared() возвращает нулевое значение и сохраняет считанное значение атрибута process-shared объекта attr в объекте, адресуемом параметром pshared; в противном случае возвращается код ошибки, обозначающий ее характер.

Ошибки

Функции pthread_condattr_getpshared () и pthread_condattr_setpshared () м огут завершиться неудачно, если:

[EINVAL]  значение, заданное пара м етром attr , недействительно.

Функция pthread_condattr_setpshared () м ожет завершиться неудачно, если:

[EINVAL]  новое значение, заданное для атрибута, не попадает в диапазон значений, действительных для этого атрибута. Эти функции не возвращают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_create (), pthread_cond_destroy (), pthread_condattr_destroy (), pthread_mutex_destroy (), то м Base Definidons стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширение м POSIX Threads Extension.

Issue 6

Функции pthread_condattr_getpshared () и pthread_condattr_setpshared () от м ечены как часть опций Threads и Thread Process-Shared Synchronization.

В целях согласования со стандартом ISO/IEC 9899: 1999 в прототип функции pthread_condattr_getpshared () было добавлено ключевое слово restrict.

pthread_create

Имя

pthread_create — функция создания потока.

Синопсис

THR

#include <pthread.h>

int pthread_create (pthread_t *restrict thread, const pthread_attr_t *restrict attr, void * (*start_routine) (void*), void *restrict arg);

Описание

Функция pthread_create() используется для создания в процессе нового потока с атрибутами, заданными параметром attr . Если значение параметра attr равно NULL, используются атрибуты, действующие по умолчанию. Если атрибуты, заданные параметром attr, будут модифицироваться позже, то на атрибуты уже созданного потока это не повлияет. При успешном завершении функция pthread_create () сохраняет ID-значение созданного потока в области памяти, адресуемой параметром thread.

При создании потока выполняется функция start_routine, которая вызывается с единственным аргументом arg . Если функция start_routine выполнится до конца, то результат будет таким, как если бы было сделано явное обращение к функции pthread_exit (), использующей в качестве состояния выхода (exit status) значение, возвращаемое функцией start_routine. Обратите внимание на то, что поток, в котором изначально вызывалась функция main(), отличается от функции start_routine. При выходе из функции main () результат будет таким, как если бы было сделано явное обращение к функции exit (), использующей в качестве состояния выхода значение, возвращаемое функцией main ().

Статус сигналов для нового потока будет инициализирован следующим образом:

• маска сигналов будет унаследована от создающего потока;

• множество необработанных сигналов для нового потока будет пустым.

Среда обработки данных с плавающей точкой будет унаследована от создающего потока.

При неудачном выполнении функции pthread_create () поток не создается, а содержимое области, адресуемое параметром thread, остается неопределенным.

TCT

Если определено значение _POSIX_THREAD_CPUTIME, новый поток получит доступ к таймеру центрального процессора (CPU-time clock), и начальное значение для этих часов будет установлено равным нулю.

Возвращаемое значение

При успешном завершении функция pthread_create () возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_create () завершится неудачно, если:

[EAGAIN] в системе недостаточно ресурсов, необходимых для создания еще одного потока, или был превышен предел ({PTHREAD_THREADS_MAX}), установленный в системе для общего количества потоков в процессе;

[EINVAL] значение, заданное параметром attr , недействительно;

[EPERM] инициатор вызова не имеет соответствующего разрешения на установку требуемых параметров планирования или стратегии планирования.

Эта функция не возвращает код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

В качестве альтернативного решения для функции pthread_create () предлагалось определить две отдельные операции: «создать» и «запустить». Для некоторых приложений такое поведение было бы более естественным. В среде Ada, в частности, отделено «создание» задачи от ее «активизации».

Разбиение этой операции на две части разработчиками стандарта было отклонено по нескольким причинам.

• Количество вызовов, требуемых для запуска потока, в этом случае возросло бы от одного до двух, что, таким образом, возложило бы излишние расходы на приложения, которым не нужна дополнительная синхронизация. Однако второго вызова можно было бы избежать за счет усложнения атрибута состояния запуска.

• Для потока пришлось бы вводить дополнительное состояние, которое можно определить как «созданный, но не активизированный». Это потребовало бы введения стандарта для определения поведения операций потока в случае, когда поток еще не начал выполняться.

• Для приложений, которым подходит именно такое поведение, можно сымитировать два отдельных действия с использованием существующих средств. Функцию start_routine () можно синхронизировать путем организации ожидания по условной переменной, сигнализируемой операцией активизации потока.

При реализации Ada-приложений можно создавать потоки в любой из двух точек Ada-программы: при создании объекта задачи или при ее активизации. В случае принятия первого варианта функции start_routine () пришлось бы ожидать по условной переменной получения «приказа» начать активизацию. Второй вариант не требует использования условной переменной или дополнительной синхронизации. В любом случае при создании объекта задачи потребовалось бы создание отдельного блока управления Ada-задачей, чтобы поддерживать рандеву-очереди.

Расширение упомянутой модели позволило бы модифицировать состояние потока между созданием и активизацией, и, следовательно, удалить объект атрибутов потока. Это предложение было отвергнуто по таким причинам.

• Должна существовать возможность установки любого состояния в объекте атрибутов потока. Это потребовало бы определения функций для модификации атрибутов потока, что не уменьшило бы количество вызовов, необходимых для установки потока. На самом деле для приложения, которое создает все потоки с использованием идентичных атрибутов, количество вызовов функций, необходимых для установки потоков, резко бы возросло. Использование объектов атрибутов потока позволяет приложению создать один набор вызовов функций установки атрибутов. В противном случае набор вызовов функций установки атрибутов пришлось бы делать для создания каждого потока.

• В зависимости от архитектурного решения функции установки состояния потока потребовали бы вызовов функций ядра системы или (по каким-то иным причинам) не могли быть реализованы как макросы, что увеличило бы расходы ресурсов на создание потока.

• Была бы утеряна возможность «классовой» организации потоков для приложений.

Предлагалась еще одна альтернатива, в которой рассматривалось использование модели, аналогичной созданию процессов, — «разветвление потока». Семантика разветвления обеспечивала бы большую гибкость, и функцию создания можно было реализовать в виде простого разветвления потока, за которым немедленно следовал вызов требуемой «запускающей» функции. Этот вариант имел такие недостатки.

• Для многих реализаций внутренний стек вызывающего потока пришлось бы дублировать, поскольку во многих архитектурах нет возможности определить размер вызывающего фрейма.

• Эффективность снизилась бы, поскольку пришлось бы копировать по крайней мере некоторую часть стека, несмотря на то, что в большинстве случаев после вызова нужной «запускающей» функции потоку уже не требуется скопированный контекст.

Будущие направления

Отсутствуют.

Смотри также

fork (), pthread_exit () , pthread_join (), то м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функция впервые реализована в выпуске Issue 5. Включена для согласования с расширением POSIX Threads Extension.

Issue 6

Функция pthread_create () от м ечена как часть опции Threads.

В результате согласования со спецификацией Single UNIX Specification был добавлен обязательный код ошибки [EPERM].

С целью согласования со ста н дарто м IEEE Std 1003.1d-1999 для потока была добавлена се м антика тай м ера центрального процессора.

Для согласования со стандарто м ISO/IEC 9899: 1999 в прототип функции pthread_create () было добавлено ключевое слово restrict.

В раздел «Описание» внесено явное утверждение о то м, что среда обработки данных с плаваю щ ей точкой наслелуется от создаю щ его потока.

pthread_detach

Имя

pthread_detach — функция отсоединения потока.

Синопсис

THR

#include <pthread.h>

int pthread_detach (pthread_t thread);

Описание

Функция pthread_detach () уведомляет реализацию о том, что область памяти для потока thread может быть восстановлена, когда он завершит выполнение. Если поток не завершается, функция pthread_detach () не служит причиной для его завершения. Результат нескольких вызовов функции pthread_detach () для одного и того же потока не определен.

Возвращаемое значение

При успешном завершении функция pthread_detach () возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_detach () завершится неудачно, если:

[EINVAL] реализация обнаружила, что значение, заданное параметром thread, не относится к присоединенному потоку;

[ESRCH] не был найден ни один поток, соответствующий заданному идентификационному номеру потока ID.

Эта функция не возвращает код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Функции pthread_join() или pthread_detach() должны вызываться для каждого потока, который создается, чтобы можно было снова использовать область памяти, связанную с потоком.

Высказывалось мнение о необязательности использования функции pthread_detach (): поскольку поток никогда динамически не отсоединяется, то достаточно использовать атрибут создания потока detachstate. Однако необходимость в этой функции возникает по крайней мере в двух случалх.

1. В обработчике запроса на отмену для функции присоединения потока (pthread__join()) важно иметь функцию pthread_detach(), чтобы отсоединить поток. Без нее обработчик вынужден был бы выполнить еще раз функцию pthread_j oin (), чтобы попытаться отсоединить поток, который не только задерживает процедуру отмены в течение неограниченного времени, но и вносит новый вызов функции pthread_join(). В этом случае есть смысл говорить о динамическом отсоединении.

2. Чтобы отсоединить «исходный поток» (это может понадобиться в процессах, которые создают потоки сервера).

Будущие направления

Отсутствуют.

Смотри также

pthread_join (), том Base Definitions стандарта IEEE Std 1003.1-2001, <pthread. h>.

Последовательность внесения изменений

Функция впервые реализована в выпуске Issue 5. Включена д ля согласования с расширение м POSIX Threads Extension.

Issue 6

Функция pthread_detach () отмечена как часть опции Threads.

pthread_exit

Имя

pthread_exit — функция завершения потока.

Синопсис

THR #include <pthread.h>

void pthread_exit (void *va2ue_ptr);

Описание

Функция pthread_exit() завершает вызывающий поток и делает значение value _ptr доступны м для успешного присоединения к завершающе м у потоку Любые обработчики отмены, которые были помещены в стек, но еще не извлечены из него, будут извлечены в порядке, обратном тому, в котором они помещались туда, а затем выполнены. Если потоку принадлежат данные, то после выполнения всех обработчиков отмены булут вызваны соответствующие функции деструкторов (в неопределенном порядке). При завершении потока ресурсы процесса, включая мьютексы и дескрипторы файлов, не освобождаются, и не выполняются какие бы то ни было «восстановительные» действия уровня процесса, включал вызовы любых функций atexit(), какие только могут существовать.

Когда из функции запуска возвращается поток, отличный от того, в котором была изначально вызвана функция main(), делается неявное обращение к функции pthread_exit(). Значение, возвращаемое этой функцией, служит в качестве состояния выхода этого потока.

Поведение функции pthread_exit () не определено, если она вызвана из обработчика запроса на отмену потока или функции деструктора, к которой было сделано обращение в результате явного или неявного вызова функции pthread_exit ().

После завершения потока результат доступа к локальным переменным потока не определен. Таким образом, ссылки на локальные переменные существующего потока не следует использовать для функции pthread_exit () в качестве значения параметра value_ptr.

После завершения процесс будет иметь состояние выхода, равное нулю, после того, как завершится его последний поток. Поведение при этом будет таким, как если бы во время завершения потока была вызвана функция exit () с нулевым аргументом.

Возвращаемое значение

Функция pthread_exit () не возвращается к инициатору ее вызова.

Ошибки

Ошибки не определены.

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Нормальный механизм завершения потока состоит в возвращении из функции, которая была задана в вызове функции pthread_create (). Функция pthread_exit () обеспечивает возможность завершения потока без обязательного выхода из стартовой функции этого потока и, следовательно, служит аналогом функции exit ().

Независимо от метода завершения потока любые обработчики отмены, которые были помещены в стек, но еще не извлечены из него, будут выполнены, а также вызваны деструкторы для любых существующих данных потока. Этот том стандарта IEEE Std 1003.1-2001 требует, чтобы обработчики отмены извлекались из стека и выполнялись по порядку. После выполнения всех обработчиков отмены для каждого элемента потоковых данных вызываются соответствующие функции деструкторов (в неопределенном порядке). Такая последовательность действий обязательна, поскольку обработчики отмены могут использовать данные потока.

Поскольку значение состояния выхода определяется приложением (за исключением случаев, когда поток был отменен, т.е. в случаях отмены используется значение PTHREAD_CANCELED), реализации не известно, что следует понимать под недействительным значением состояния, поэтому проверка на наличие ошибок не выполняется.

Будущие направления

Отсутствуют.

Смотри также

exit (), pthread_create (), pthread_join (), том Base Definitions стан д арта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функция впервые реализована в выпуске Issue 5. Включена для со г ласования с расширение м POSIX Threads Extension.

Issue 6

Функция pthread_exit () от м ече н а как часть опции Threads.

pthread_getconcurrency, pthread_setconcurrency

Имя

pthread_getconcurrency, pthread_setconcurrency — функции считывания и установки уровня параллелизма.

Синопсис

XSI

#include <pthread.h>

int pthread_getconcurrency (void);

int pthread_setconcurrency (int new_level);

Описание

Несвязанные потоки в процессе выполняются (или не выполняются) одновременно. По умолчанию реализация потоков гарантирует активность достаточного количества потоков для того, чтобы процесс мог успешно продолжать выполнение. И хотя такой подход сохраняет системные ресурсы, он может не обеспечить наиболее эффективный уровень параллелизма.

Функция pthread_setconcurrency () позволяет приложению с помощью пара м етра new_level информировать реализацию потоков о желаемом уровне параллелизма. Реальный же уровень параллелизма, обеспечиваемый реализацией в результате вызова этой функции, не определен. Если значение параметра new_level равно нулю, это означает, что реализация должна поддерживать уровень параллелизма таким, как если бы функция pthread_setconcurrency () никогда не вызывалась.

Функция pthread_getconcurrency () возвращает значение, установленное в результате предыдущего обращения к функции pthread_setconcurrency (). Если «предыдущего» вызова этой функции не было, функция pthread_getconcurrency () возвращает нуль, который означает, что реализация поддерживает заданный уровень параллелизма.

Обращение к функции pthread_setconcurrency () информирует реализацию о желаемом уровне параллелизма, а реализация использует его как совет, а не требование.

Если реализация не поддерживает мультиплексирование пользовательских потоков, то функции pthread_setconcurrency() и pthread_getconcurrency() используются ради совместимости исходного кода, но не дают никакого эффекта при вызове. Для поддержки семантики функций параметр new_level сохраняется при вызове функции pthread_setconcurrency (), чтобы послелующее обращение к функции pthread_getconcurrency () могло вернуть то же значение.

Возвращаемые значения

При успешном выполнении функция pthread_setconcurrency() возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Функция pthread_getconcurrency () всегда возвращает уровень параллелизма, установленный в результате предыдущего обращения к функции pthread_setconcurrency (). Если «предыдущего» вызова этой функции не было, функция pthread_getconcurrency () возвращает нуль.

Ошибки

Фу н кци я pthread_setconcurrency () завершится неудачно, если:

[EINVAL ] значение, заданное пара м етро м new_level , отрицательно;

[EAGAIN] значение, заданное пара м етро м new_level, приводит к перерасхолу систе м ных ресурсов.

Эти функции не возвращают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Использование этих функций изменяет состояние базового уровня параллелизма, от которого зависит работа приложения. Разработчикам библиотек рекомендуется не использовать функции pthread_getconcurrency() и pthread_setconcurrency(), поскольку это может привести к конфликту с их использованием в приложении.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

То м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5.

pthread_getschedparam, pthread_setschedparam

Имя

pthread_getschedparam, pthread_setschedparam — функции динамического доступа к параметрам стратегии планирования потока (REALTIME THREADS).

Синопсис

THR TPS

#include <pthread.h>

int pthread_getschedparam (pthread_t thread, int *restrict policy, struct sched_param *restrict param);

int pthread_setschedparam (pthread_t thread, int policy, const struct sched_param *param);

Описание

Функции pthread_getschedparam() и pthread_setschedparam() используются для считывания и установки соответственно значений стратегии планирования и параметров отдельных потоков многопоточного процесса. Для значений стратегии планирования SCHED_FIFO и SCHED_RR в структуре sched_param должен быть установлен только один ее член sched_priority [27] (уровень приоритета). Для значения SCHED_OTHER параметры планирования определяются реализацией.

Функция pthread_getschedparam() пре д назначена для считывания значения стратегии пла н ирования и пара м етров планирования для потока, идентификационный но м ер (ID) которого задан пара м етро м thread. Считанные значения сохраняются в пара м етрах policy и param. Функция pthread_getschedparam() возвра щ ает значение приоритета, установленное в результате са м ого последнего вызова функций pthread_setschedparam(), pthread_setschedprio() или pthread_create () для данного потока. Она не отражает никаких временных корректировок, вносимых в значение приоритета в результате выполнения других функций. Функция pthread_setschedparam() устанавливает для потока, ID которого за д ан пара м етро м thread, стратегию планирования и соответствую щ ие пара м етры планирования равны м и значения м пара м етров policy и nparam соответственно.

Параметр роlicy м ожет и м еть значения SCHED_OTHER, SCHED_FIFO или SCHED_RR. Параметры планирования для стратегии планирования, заданной значением SCHED_OTHER, определяются реализацией. Для страте г ии планирования, задавае м ой значения м и SCHED_FIFO и SCHED_RR, используется только один пара м етр priority.

TSP

Если определено значение _POSIX_THREAD_SPORADIC_SERVER, аргу м ент роlicy может иметь значение SCHED_SPORADIC (за исключение м функции pthread_setschedparam()). Если стратегия планирования в момент вызова этой функции не соответствовала значению SCHED_SPORADIC, то поддержка этого значения определяется реализацией, т.е. реализация может не позволить приложению динамически изменять стратегию планирования, устанавливая ee равной значению SCHED_SPORADIC. Для стратегии планирования, определяе м ой значение м SCHED_SPORADIC, устанавливаются такие пара м етры: sched_ss_low_priority, sched_ss_repl_period, sched_ss_init_budget, sched_priority и sched_ss_max_repl. Для успешного выполнения фу н кции установки пара м етров значение пара м етра sched_ss_repl_period должно быть больше или равно значению sched_ss_init_budget; в противном случае функция завершится неудачно. Кро м е того, для успешного выполнения этой функции значение пара м етра sched_ss_max_repl должно попадать во включающий диапазон [1, SS_REPL_MAX] ; в противном случае функция завершится неудачно.

При неудачном завершении функции pthread_setschedparam() параметры планирования для заданного потока изменены не будут.

Возвращаемые значения

П ри успешно м завершении функции pthread_getschedparam() Hpthread_setschedparam() возвра щ ают нулевое значение; в противно м случае — кодошибки, обозначаю щ ий ее характер.

Ошибки

Функци я pthread_getschedparam () м ожет завершитьс я неудачно, если:

[ESRCH]  з н ачение, заданное пара м етро м thread, не относится ни к од-

ному из существующих потоков.

Функция pthread_setschedparam() может завершиться неудачно, если:

[EINVAL]  значение, заданное параметром policy, или значение одного из параметров планирования, связанных со значением стратегии планирования policy, недействительно;

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

была сделана попытка динамически изменить стратегию планирования, установив для нее значение SCHED_SPORADIC, при том, что реализация не поддерживает такое изменение;

инициатор вызова не имеет соответствующего разрешения устанавливать параметры планирования или стратегию планирования для заданного потока;

реализация не позволяет приложению модифицировать один из параметров в соответствии с заданным значением;

значение, заданное пара м етро м thread, не относится ни к одному из существующих потоков.

Эти функции не возвращают код ошибки [EINTR].

[ENOTSUP]

TSP [ENOTSUP]

[EPERM]

[EPERM]

[ESRCH]

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_setschedprio (), sched_getparam(), sched_getscheduler (), то м Base Definitions craHjapTaIEEEStd 1003.1-2001, <pthread.h>, <sched.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширением POSIX Threads Extension.

Issue 6

Функции pthread_getschedparam() и pthread_setschedparam() от м ечены как часть опций Threads и Thread Execution Scheduling.

Код ошибки [ENOSYS] был исключен, поскольку е г о нет с м ысла учитывать, если реализация не под д ерживает опцию Thread Execution Scheduling.

К описанию прототипа функции pthread_setschedparam() был приложен список опечаток Open Group Corrigendum U026/2, чтобы второй ар г у м ент этой функции и м ел тип int.

Для согласования со стандартом IEEE Std 1003.1d-1999 было добавлено значение стратегии планирования SCHED_SPORADIC.

В целях согласования со стандартом ISO/IEC 9899: 1999 в прототип функции pthread_getschedparam () было добавлено ключевое слово restrict.

Был добавлен список опечаток Open Group Corrigendum U047/1.

Быладобавлена интерпретация IEEE PASC 1тегрге1а1юп 1003.1 #96, отмечающая» что значения приоритета также можно установить путем вызова функции pthread_setschedprio().

pthread_join

Имя

pthread_join — функция ожидания завершения потока.

Синопсис

THR

#include <pthread.h>

int pthread_join (pthread_t thread, void **value _ptr);

Описание

Функция pthread_join() приостанавливает выполнение вызывающего потока до тех пор, пока не завершится заданный поток (если он еще не завершился). Если после удачного возвращения из функции pthread_join () параметр value_ptr не равен значению NULL значение, передавае м ое функции pthread_exit() завершающимся потоком, будет доступным в области памяти, адресуемой параметром value_ptr. Успешное выполнение функции pthread_join () означает, что заданный поток завершился. Результаты нескольких одновременных обращений к функции pthread_join (), в параметрах которых задается один и тот же поток, не определены. Если поток, вызывающий функцию pthread_join(), отменен, то заданный поток не будет выгружен.

Не определено, учитывается ли в значении {PTHREAD_THREADS_MAX} поток, который завершился, но остался отсоединенным.

Возвращаемые значения

При успешном завершении функция pthread_join () возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_join () завершится неудачно, если:

[EINVAL]  реализация обнаружила, что значение, заданное параметром thread, не относится ни к одному из присоединенных потоков;

[ESRCH]  не найден ни один поток, идентификационный номер которого (ID) соответствовал бы заданному потоку.

Функция pthread_join () может завершиться неудачно, если:

[EDEADLK]  была обнаружена взаимоблокировка или значение параметра thread соответствует вызывающему потоку.

Функция pthread_join () не возвращает код ошибки [EINTR].

Примеры

Ниже приведен пример создания потока и его удаления.

typedef struct {

int *ar;

long n;

} subarray;

void *incer (void *arg) {

long i;

for (i = О; i < ((subarray *)arg) ->n; i++) ((subarray *) arg) ->ar[i]++;

}

int main (void) {

int ar[1000000];

pthread_t th1, th2;

subarray sbl, sb2;

sbl.ar = &ar[О];

sbl.n = 500000;

(void) pthread_create(&thl, NULL, incer, &sbl);

sb2.ar = &ar[500000];

sb2.n = 500000;

(void) pthread_create(&th2, NULL, incer, &sb2);

(void) pthread_join(thl, NULL);

(void) pthread_join(th2, NULL);

return 0;

}

Замечания по использованию

Отсутствуют.

Логическое обоснование

Функция pthread_join() представляет собой удобное и полезное средство для использования в многопоточных приложениях. Конечно, программист мог бы сымитировать эту функцию, если бы она не существовала, другими средствами, например, путем передачи функции start_routine () дополнительного состояния как части аргумента. Завершающийся поток в этом случае установил бы флаг, означающий завершение, и отправил бы условную переменную, которая является частью этого состояния, а присоединяющий поток ожидал бы получения этой условной переменной. Несмотря на то что такой метод позволил бы организовать ожидание наступления более сложных условий (например, завершения сразу нескольких потоков), ожидание завершения одного потока— весьма распространенная ситуация, и поэтому «заслуживает» отдельной функции. Кроме того, включение в библиотеку функции pthread_join () никоим образом не мешает программисту самому кодировать такие сложные ожидания. Таким образом, включение функции pthread_join () в этот том стандарта IEEE Std 1003.1-2001 считается весьма полезным.

Функция pthread_join() обеспечивает простой механизм, позволяющий приложению ожидать завершения потока. После того как поток завершится, приложение может приступать к освобождению ресурсов, которые использовались этим потоком.

Например, после возвращения функции pthread_join () может быть восстановлена любая область памяти, предоставленная приложением под стек.

Функции pthread_join () или pthread_detach () должны в конце концов быть вызваны для каждого потока, который создается с атрибутом detachstate, равным значению PTHREAD_CREATE_JOINABLE , чтобы м ожно было восстановить память, связанную с потоком.

Взаимодействие между функцией pthread_join () и механизмом отмены потока хорошо определено по следующим причинам:

• функция pthread_join (), как и все остальные не асинхронные функции безопасной отмены потоков, можно вызывать только при возможности отложенного типа отмены.

• отмена потока не может происходить в состоянии запрещения отмены.

Таким образом, имеет смысл рассматривать только стандартное состояние возможности отмены. Итак, вызов функции pthread_join() либо отменяется, либо успешно завершается. Для приложения это различие очевидно, поскольку либо выполняется обработчик запроса на отмену, либо возвращается функция pthread_join (). В этом случае условия «гонок» не возникают, поскольку функция pthread_join() вызывается в состоянии отложенного запроса на отмену.

Будущие направления

Отсутствуют.

Смотри также

pthread_create(), wait(), том Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функция впервые реализована в выпуске Issue 5. Включена для согласования с расширение м POSIX Threads Extension.

Issue 6

Функция pthread_join () отмечена как часть опции Threads.

pthread_mutex_destroy, pthread_mutex_init

Имя

pthread_mutex_destroy, pthread_mutex_init — функции разруше н ия и инициализации мьютекса.

Синопсис

THR

#include <pthread.h>

int pthread_mutex_destroy (pthread_mutex_t *^utex);

int pthread_mutex_init (

pthread_mutex_t *restrict jnutex,

const pthread_mutexattr_t *restrict attr);

pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;

Описание

Функция pthread_mutex_destroy () используется для разрушения объекта мьютекса, адресуемого параметром mutex, в результате чего этот объект мьютекса становится неинициализированным. В конкретной реализации функция pthread_mutex_destroy () может устанавливать объект, адресуемый параметром mutex, равным недействительному значению. Разрушенный объект мьютекса можно снова инициализировать с помощью функции pthread_mutex_init(); результаты ссылки на этот объект после его разрушения не определены.

Нет никакой опасности в разрушении инициализированного объекта мьютекса, по которому не заблокирован в данный момент ни один поток. Попытка же разрушить заблокированный мьютекс может привести к неопределенно м у поведению.

Функция pthread_mutex_init () используется для инициализации м ьютекса, адресуе м ого пара м етро м mutex, объекто м атрибутов, адресуемым параметром attr. Если параметр attr содержит значение NULL, для инициализации применяются атрибуты мьютекса, действующие по умолчанию, т.е. результат в этом случае равносилен передаче адреса объекта, содержащего стандартные атрибуты мьютекса. После успешной инициализации мьютекс становится инициализированным и разблокированным.

Для осуществления синхронизации используется только сам объект, адресуемый параметром mutex. Результат ссылки на копии объекта mutex в обращениях к функциям pthread_mutex_lock(), pthread_mutex_trylock(), pthread_mutex_unlock() и pthread_mutex_destroy () не определен.

Попытка инициализировать уже инициализированный объект мьютекса приведет к неопределенному поведению.

В случаях, когда атрибуты мьютекса, действующие по умолчанию, заранее определены, для инициализации мьютексов, которые создаются статически, можно использовать макрос PTHREAD_MUTEX_INITIALIZER. Резу л ьтат в этом с л учае эквивалентен динамической инициализации путем вызова функции pthread_mutex_init () с параметром attr, равным значению NULL, но без выпо л нения проверки на наличие ошибок.

Возвращаемые значения

При успешном завершении функции pthread_mutex_destroy() и pthread_ mutex_init () возвращают нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Проверка на наличие ошибок с кодами [EBUSY] и [EINVAL] реализована так (если реализована вообще), как будто она выполняется в самом начале работы каждой функции, и код ошибки в случае ее обнаружения возвращается до модификации состояния мьютекса, заданного параметром mutex.

Ошибки

Функция pthread_mutex_destroy () может завершиться неудачно, если:

[EBUSY]  реализация обнаружила попытку разрушить объект, адресуе м ый параметром mutex, который относится к другому потоку (напри м ер, при использовании в функциях pthread_mutex_wait () или pthread_mutex_timedwait ()), или указанный объект заблокирован;

[EINVAL] значение, заданное пара м етро м mutex, недействительно.

Функция pthread_mutex_init () завершится неудачно, если:

[EAGAIN] система испытывает недостаток ресурсов (не имеется в виду память), необходимых для инициализации еще одного мьютекса;

[ENOMEM] для инициализации мьютекса недостаточно существующей памяти;

[EPERM]  инициатор вызова функции не имеет привилегий для выполнения этой операции.

Функция pthread_mutex_init () м ожет завершиться неудачно, если:

[EBUSY]  реализация обнаружила попытку повторно инициализировать объект мьютекса, адресуемый параметром mutex, которой был ранее инициализирован, но еще не разрушен;

[EINVAL ] значение, заданное пара м етро м attr, недействительно. Эти функции не возвра щ ают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Возможность альтернативных реализаций

Данный том стандарта IEEE Std 1003.1-2001 поддерживает несколько альтернативных реализаций мьютексов. Реализация может сохранять блокировку непосредственно в объекте типа pthread_mutex_t. Возможно также хранение блокировки в «куче», а указателя, дескриптора или уникального ID — в объекте мьютекса. Каждая реализация обладает различными достоинствами в зависимости от определенных конфигураций оборудования. Поэтому, чтобы написать код, который не нужно будет изменять в зависимости от выбранной реализации, в данном томе стандарта IEEE Std 1003.1-2001 жестко не определяется тип хранения блокировки и термин «инициализировать» используется для усиления утверждения о том, что блокировка может в действительности располагаться в самом объекте мьютекса.

Обратите вни м ание на то, что это устраняет избыточность определения типа м ьютекса или условной пере м енной.

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

Компромисс между контролем за ошибками и производительностью

Существует множество случаев, когда можно обойтись без проверки на наличие ошибок ради достижения более высокой производительности. Полнота применения контроля за ошибками должна соответствовать нуждам конкретных приложений и возможностям сред выполнения. В общем случае об ошибках или ошибочных условиях, вызванных системными причинами (например, недостаточностью памяти), необходимо уведомлять всегда, но необязательно сообщать об ошибках, связанных с некорректностью кода приложения (например, при неудачной попытке обеспечить адекватную синхронизацию, используемую при защите мьютекса от удаления).

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

Предусмотрительно ограничивая использование понятия «неопределенное поведение» только случаями ошибочных действий самого приложения (по причине недостаточно продуманного кода) и обязательно определяя ошибки, связанные с недоступностью системных ресурсов, данный том стандарта IEEE Std 1003.1-2001 гарантирует, что любое корректно написанное приложение переносимо в полном диапазоне реализаций, но не обязывает все реализации нести дополнительные затраты на проверку многочисленных условий, которые корректно написанная программа никогда не создаст.

Почему не определяются предельные значения

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

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

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

Без применения статической инициализации функция самоинициализации foo () может иметь следующий вид.

static pthread_once_t foo_once = PTHREAD_ONCE_INIT;

static pthread_mutex_t foo_mutex;

void foo_init () {

pthread_mutex_init (&foo_mutex, NULL);

}

void foo() {

pthread_once(&foo_once, foo_init);

pthread_mutex_lock (&foo_mutex);

/* Выполнение действий. */

pthread_mutex_unlock (&foo_mutex);

}

С применением статической инициализации ту же функцию самоинициализации foo() м ожно было бы закодировать таки м образо м.

static pthread_mutex_t foo_mutex = PTHREAD_MUTEX_INITIALIZER;

void foo()

{

pthread_mutex_lock(&foo_mutex) ;

/* Выполнение действий. */

pthread_mutex_unlock(&foo_mutex);

}

Обратите внимание на то, что статическая инициализация устраняет необходимость в тестировании, проводимом в функции pthread_once (), и получении значения адреса &foo_mutex, передаваемого функции pthread_mutex_lock() или pthread_mutex_unlock ().

Таким образом, С-код, написанный для инициализации статических объектов, проще во всех системах и работает быстрее на большом классе систем, в которых объект (внутренней) синхронизации можно хранить в памяти приложения.

До сих пор вопрос о быстродействии блокировок поднимался для машин, которые требовали, чтобы для мьютексов выделялась специальная память. В действительности в таких машинах мьютексы и, возможно, условные переменные должны были содержать указатели на реальные аппаратные средства защиты. Для того чтобы на таких машинах работала статическая инициализация, функция pthread_mutex_lock () также должна проверять, выделена ли память для указателя на реальный объект блокировки. Если не выделена, функция pthread_mutex_lock (), прежде чем его использовать, должна его инициализировать. Резервирование таких ресурсов можно выполнить при загрузке программы, и поэтому для мьютексов и условных переменных не были введены дополнительные коды ошибок, означающие неудачное выполнение инициализации.

Такое динамическое тестирование в функции pthread_mutex_lock(), которое позволяет узнать, был ли инициализирован указатель, могло показаться на первый взгляд лишним. На большинстве компьютеров это было бы реализовано в виде считывания его значения, сравнения с нулем и использования по назначению при условии получения нужного результата сравнения. Несмотря на то что это тестирование кажется лишним, дополнительные затраты (на тестирование содержимого регистра) обычно незначительны, поскольку в действительности никакие дополнительные ссылки на память не делаются. Так как все больше и больше компьютеров оснащаются кэш-памятью (быстродействующей буферной памятью большой емкости), то реальные издержки представляют собой отработку ссылок, а не выполнение инструкций.

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

Расходы на блокировку для компьютеров, выполняющих «внешнюю» инициализацию мьютекса, сравнимы с расходами для модулей, инициализируемых неявным образом (имеются в виду те из них, где достигнута «внутренняя» инициализация мьютексов). Безусловно, «внутренняя» инициализация выполняется гораздо быстрее, но «внешняя» ненамного хуже.

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

Наконец, если ни один из описанных выше методов оптимизации для «внешнего» размещения объектов синхронизации не позволяет достичь нужной производительности приложения при использовании определенной реализации, приложение может избежать статической инициализации, явным образом инициализируя все объекты синхронизации c помощью соответствующих функций pthread_*_init(), которые поддерживаются всеми реализациями. В документации на реализацию также могут быть описаны компромиссные решения и рекомендации относительно того, какие методы инициализации являются наиболее эффективными для данной конкретной реализации.

Разрушение мьютексов

Мьютекс можно разрушить сразу после разблокировки. Например, рассмотрим следующий код.

struct obj {

pthread_mutex_t om;

int refcnt;

};

obj_done (struct obj *op) {

pthread_mutex_lock (&op- >om);

if (—op- >refcnt == 0) {

pthread_mutex_unlock (&op- >om);

(A) pthread_mutex_destroy (&op- >om);

(B) free(op); } else

(С) pthread_mutex_unlock (&op->om);

}

В данном случае структура obj служит для учета количества ссылок, а функция obj_done() вызывается всякий раз, когда удаляется ссылка на объект. Реализации должны позволить разрушение объекта и освобождение занимаемых им ресурсов (см. строки А и В) сразу после его разблокировки (строка С).

Будущие направления

Отсутствуют.

Смотри также

pthread_mutex_getprioceiling (), pthread_mutex_lock (), pthread_mutex_timedlock (), pthread_mutexattr_getpshared (), том Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширение м POSIX Threads Extension.

Issue 6

Функции pthread_mutex_destroy() и pthread_mutex_init() от м ечены как часть опции Threads.

В целях согласования со стандарто м IEEE Std 1003.1d-1999 в раздел «С м отри также» была добавлена функция pthread_mutex_timedlock ().

Раздел «Описание» б ы л отредактирован путе м при м енения интерпретации IEEE PASC Interpretation 1003.1с #34.

В целях согласования со стандартом ISO/IEC 9899: 1999 в прототип функции pthread_mutex_init () было добавлено ключевое слово restrict.

pthread_mutex_getprioceiling, pthread_mutex_setprioceiling

Имя

THR TPP

pthread_mutex_getprioceiling, pthread_mutex_setprioceiling — функции считывания и установки предельного значения приоритета мьютекса (REALTIME THREADS).

Синопсис

#include <pthread.h>

int pthread_mutex_getprioceiling (

const pthread_mutex_t *restrict mutex, int *restrict prioceiling) ; int pthread_mutex_setprioceiling (

pthread_mutex_t *restrict mutex, int prioceiling, int *restrict old_ceiling) ;

Описание

Функция pthread_mutex_getprioceiling() используется для считывания теку щ его значения предельного приоритета м ьютекса. Функция pthread_mutex_setprioceiling() сначала блокирует м ьютекс, если он разблокирован, или надежно удерживает его в заблокированно м состоянии, а зате м изменяет значение предельного приоритета мьютекса и после этого освобождает его. При успешном изменении приоритета его предыдущее значение возвращается с помощью параметра old__ceiling. В процессе блокирования мьютекса нет необходимости привязываться к протоколу за щ иты приоритета.

При неудачном выполнении функции pthread_mutex_setprioceiling() предельное значение приоритета мьютекса не будет изменено.

Возвращаемые значения

При успешном завершении функции pthread_mutex_getprioceiling() и pthread_mutex_setprioceiling() возвращают нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функции pthread_mutex_getprioceiling () и pthread_mutex_setprioceiling () могут завершиться неудачно, если:

[EINVAL]  приоритет, заданный пара м етро м prioceiling, не попадает в нужный диапазон:

[EINVAL]  значение, заданное пара м етро м mutex, не относится ни к одно м у из существующих мьютексов;

[ EPERM]  инициатор вызова не и м еет привиле г ий д л я выпо л нения этой операции.

Эти функции не возвра щ ают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_mutex_destroy(),pthread_mutex_lock(),

pthread_mutex_timedlock (), то м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширением POSIX Threads Extension.

Отмечены как часть группы Realtime Threads Feature Group.

Issue 6

Функции pthread_mutex_getprioceiling () и pthread_mutex_setprioceiling () отмечены как часть опций Threads и Thread Execution Scheduling.

Код ошибки [ENOSYS] был исключен, поскольку его нет смысла учитывать, если реализация не поддерживает опцию Thread Priority Protection.

Код ошибки [ENOSYS], обозначающий отсутствие поддержки протокола учета приоритета для мьютексов, был исключен. Дело в том, что если реализация предоставляет эти функции (независимо от того, определено ли значение _POSIX_PTHREAD_PRIO_PROTECT), они должны работать так, как отмечено в разделе «Описание», т.е. протокол учета приоритета для мьютексов должен поддерживаться.

В целях согласования со стандартом IEEE Std 1003.1d-1999 в раздел «Смотри также была добавлена функция pthread_mutex_timedlock ().

В целях согласования со стандартом ISO/IEC 9899: 1999 в прототипы функции pthread_mutex_getprioceiling() и pthread_mutex_setprioceiling() было добавлено ключевое слово restrict.

pthread_mutex_lock, pthread_mutex_trylock, pthread_mutex_unlock

Имя

pthread_mutex_lock, pthread_mutex_trylock, pthread_mutex_unlock — функции блокировки и разблокировки мьютекса.

Синопсис

THR #include <pthread.h>

int pthread_mutex_lock (pthread_mutex_t *.mutex) ; int pthread_mutex_trylock (pthread_mutex_t *mutex); int pthread_mutex_unlock (pthread_mutex_t *mutex);

Описание

Объект мьютекса, адресуемый параметром mutex, блокируется путем вызова функции pthread_mutex_lock(). Если мьютекс уже заблокирован, вызывающий поток блокируется до тех пор, пока мьютекс не станет доступным. При завершении этой операции объект мьютекса, адресуемый параметром mutex, находится в состоянии блокировки, а вызывающий поток является его владельцем.

XSI  Ес л и м ьютекс и м еет тип PTHREAD_MUTEX_NORMAL , обнаружение взаимоблокировок не обеспечивается. К взаимоблокировке может привести попытка заблокировать мьютекс повторно. Если поток попытается разблокировать мьютекс, который не заблокирован, дальнейшее ero поведение не определено.

Для мьютексов типа PTHREAD_MUTEX_ERRORCHECK предусмотрена проверка на наличие ошибок. Если поток попытается заблокировать мьютекс, который уже заблокирован, возвращается ошибка. Если поток попытается разблокировать мьютекс, который не заблокирован, возвращается ошибка.

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

Если м ьютекс и м еет тип PTHREAD_MUTEX_DEFAULT, попытка рекурсивно заблокировать мьютекс приводит к неопределенному поведению. Попытка разблокировать мьютекс, который не был заблокирован (любым потоком, включал вызывающий), приводит к неопределенному поведению.

Функция pthread_mutex_trylock () эквивалентна функции

pthread_mutex_lock (), за исключением того, что если объект мьютекса, адресуемый параметром mutex, в данный момент заблокирован (любым потоком, включал текущий), эта функция немедленно завершится. Если мьютекс имеет тип PTHREAD_MUTEX_RECURSIVE , и в данный момент мьютексом владеет вызывающий поток, счетчик блокировок этого мьютекса инкрементируется, а функция pthread_mutex_trylock () немедленно возвращает признак успешного завершения.

Функция pthread_mutex_unlock () освобождает объект м ьютекса, адресуе м ый пара м етро м mutex.

XSI  Способ освобождения зависит от атрибута типа м ьютекса.

Если при вызове функции pthread_mutex_unlock (), в результате которого мьютекс стал доступным, существуют потоки, заблокированные по объекту мьютекса, адресуемому параметром мьютекс, то поток-владелец этого мьютекса будет установлен стратегией планирования. XSI

(Для м ьютексов типа PTHREAD_MUTEX_RECURS IVE: м ьютекс становится доступным, когда счетчик блокировок достигает нуля, и вызывающий поток больше не имеет никаких блокировок по этому мьютексу.)

Если к потоку, ожидающему освобождения мьютекса, поступает сигнал, то после выполнения обработчика этого сигнала поток снова перейдет в состояние ожидания, как если бы он и не прерывался на обработку сигнала.

Возвращаемые значения

При успешном завершении функции pthread_mutex_lock() npthread_mutex_unlock() возвращают нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Функция pthread_mutex_trylock () возвращает нулевое значение, если выполнена блокировка по объекту мьютекса, адресуемому параметром mutex. В противном случае возвращается код ошибки, обозначающий ее характер.

Ошибки

Функции pthread_mutex_lock () и pthread_mutex_trylock () завершатся неудачно, если:

[EINVAL] мьютекс был создан с использованием атрибута protocol, имеющего значение PTHREAD_PRIO_PROTECT, а приоритет вызывающего потока выше текущего значения предельного приоритета мьютекса.

Функция pthread_mutex_trylock () завершится неудачно, если:

[EBUSY] мьютекс остался недоступным, поскольку он был уже заблокирован.

Функции pthread_mutex_lock() , pthread_mutex_trylock()

и pthread_mutex_unlock () м огут завершиться неудачно, если:

[EINVAL] значение, заданное пара м етро м mutex, не относится к инициализированно м у объекту м ьютекса;

XSI [EAGAIN] мьютекс остался недоступным, поскольку было превышено максимальное количество рекурсивных блокировок для мью-текса, заданного параметром mutex.

Функция pthread_mutex_lock () м ожет завершиться неудачно, ес л и:

[ EDEADLK ]  текущий поток уже владеет мьютексом.

Функция pthread_mutex_unlock () м ожет завершиться неудачно, ес л и:

[ EPERM ]  текущий поток не владеет мьютексом.

Эти функции не возвра щ ают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

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

Функции управления мьютексами и, в частности, устанавливаемые по умолчанию значения атрибутов мьютексов позволяют по желанию организовать быстродействующие встроенные реализации блокировок и разблокировок мьютексов.

Например, тупиковая ситуация при двойной блокировке— это явным образом разрешенное поведение, которое позволяет избежать внесения в базовый механизм больших затрат. (Более «дружественные» мьютексы, которые обнаруживают взаимоблокировку или позволяют множественное блокирование одним и тем же потоком, пользователь может легко создать с помощью других механизмов. Например, для регистрации владельцев мьютекса можно использовать функцию pthread_self.) Реализации путем использования специальных атрибутов мьютексов также могут предоставлять дополнительные возможности в виде опций.

Поскольку большинство атрибутов проверяется перед тем, как поток должен быть заблокирован, их использование не замедляет процесс блокирования мьютекса.

Более того, несмотря на возможность выделить идентификационный номер (ID) владельца мьютекса, это потребовало бы сохранения текущего ID потока при каждом блокировании мьютекса, что связано с неприемлемым уровнем затрат. Аналогичные аргументы применимы и к операции mutex_tryunlock.

Будущие направления

Отсутствуют.

Смотри также

pthread_mutex_destroy (), pthread_mutex_timedlock (), то м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования c расширением POSIX Threads Extension.

Issue 6

Функции pthread_mutex_lock (), pthread_mutex_trylock () и pthread_mutex_ unlock () отмечены как часть опции Threads.

В результате согласования со спецификацией Single UNIX Specification было определено поведение при попытке повторно заблокировать мьютекс.

В целях согласования со стандартом IEEE Std 1003.1d-1999 в раздел «Смотри также» была добавлена функция pthread_mutex_timedlock ().

Пр и ложе ни е Б 607

pthread_mutex_timedlock

Имя

pthread_mutex_timedlock — функция блокировки мьютекса (ADVANCED REALTIME).

Синопсис

THR

#include <pthread.h>

TMO

#include <time.h>

int pthread_mutex_timedlock ( pthread_mutex_t *restrict mutex, const struct timespec *restrict abs_timeout);

Описание

Функция pthread_mutex_timedlock() используется для блокирования объекта мьютекса, адресуемого параметром mutex . Если этот мьютекс уже заблокирован, блокируется вызывающий поток до тех пор, пока мьютекс не станет доступным (как при использовании функции pthread_mutex_lock()). Если мьютекс нельзя заблокировать без ожидания, пока другой поток его разблокирует, это ожидание будет прервано, когда истечет заданный интервал времени.

Заданный интервал времени истекает, когда наступит абсолютное время, заданное параметром abs_timeout (т.е. ког д а значение систе м ных часов станет равны м или превысит значение abs_timeout) или если в момент вызова функции абсолютное время, заданное пара м етро м abs_timeout, уже наступило.

TMR Если поддерживается опция Timers, отсчет интервала вре м ени проис ходит с использованием часов CLOCK_REALTIME; в противном случае — с использованием системных часов, значение которых возвращает функция time ().

Разрешение для интервала времени определяется разрешением часов, которые используются для его отсчета. Тип данных timespec определяется в заголовке <time. h>.

Ни при каких условиях эта функция не завершится неудачно, если мьютекс может быть заблокирован немедленно. В проверке д остоверности пара м етра abs_timeout нет никакой необходимости, если мьютекс может быть заблокирован немедленно.

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

Возвращаемое значение

При успешном завершении функция pthread_mutex_timedlock() возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_mutex_timedlock () завершится неудачно, если:

[EINVALJ  мьютекс был создан с использованием атрибута protocol, и м еющего значение PTHREAD_PRIO_PROTECT, а приоритет вызывающего потока выше текущего значения предельного приоритета м ьютекса;

[EINVAL]  процесс или поток заблокирован, а пара м етр abs_timeout в поле наносекунд и м еет значение, которое м еньше нуля либо больше или равно 1000 млн;

[ETIMEDOUT] мьютекс не удалось заблокировать до истечения заданного интервала времени.

Функция pthread_mutex_timedlock () может завершиться неудачно, если:

[EINVAL] значение, заданное пара м етро м mutex, не относится к инициализированному объекту мьютекса; XSI [EAGAIN] мьютекс остался недоступным, поскольку было превышено максимальное количество рекурсивных блокировок для мьютекса, заданного параметром mutex

[ EDEADLK] текущий поток уже владеет мьютексом.

Эта функция не возвращает код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Функция pthread_mutex_timedlock() является частью опций Threads и Timeouts и м ожет быть не представлена во всех реализациях.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_mutex_destroy (), pthread_mutex_lock(), pthread_mutex_trylock(), time (), то м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread. h>, <time. h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 6, основанием послужил стандарт IEEEStd 1003.1d-1999.

pthread_mutexattr_destroy

Имя

pthread_mutexattr_destroy

Синопсис

THR #include <pthread.h>

int pthread_mutexattr_destroy (

pthread_mutexattr_t *attr); int pthread_mutexattr_init (pthread_mutexattr_t *attr);

Описание

Функция pthread_mutexattr_destroy () используется для разрушения объекта атрибутов м ьютекса, в результате чего этот объект становится неинициализированным. В конкретной реализации функция pthread_mutexattr_destroy() м ожет устанавливать объект, адресуе м ый пара м етро м attr, равны м недействительно м у значению. Разрушенный объект атрибутов м ожно снова инициализировать с по м о щ ью функции pthread_mutexattr_init (); результаты ссылки на этот объект после его разрушения не определены.

Результаты не определены, если функция pthread_mutexattr_init () вызывается, ссылаясь на уже инициализированный объект атрибутов attr.

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

Возвращаемые значения

При успешно м завершении функции pthread_mutexattr_destroy() и pthread_mutexattr_init () возвра щ ают нулевое значение; в противно м случае — код ошибки, обозначаю щ ий ее характер.

Ошибки

Функция pthread_mutexattr_destroy () м ожет завершиться неудачно, если:

[EINVAL ]  значение, заданное параметром attr, недействительно.

Функция pthread_mutexattr_init () завершится неудачно, если:

[ENOMEM]  для инициализации объекта атрибутов м ьютекса недостаточно существующей памяти.

Эти функции не возвра щ ают код ошибки [EINTR].

pthread_mutexattr_destroy, pthread_mutexattr_init — функции разрушения и инициализации объекта атрибутов м ьютекса.

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Для получения общих разъяснений назначения атрибутов см. описание функции pthread_attr_init (). Объекты атрибутов позволяют реализациям экспериментировать с полезными расширениями и разрешают использовать расширение этого тома стандарта IEEE Std 1003.1-2001, не изменяя существующих функций. Таким образом, они обеспечивают возможности для будущего расширения этого тома стандарта IEEE Std 1003.1-2001 и уменьшают соблазн преждевременно стандартизировать семантику, которая еще широко не реализована или не до конца понята.

Рассматривалась возможность использования таких дополнительных атрибутов мьютексов, как spin__only, limited spin, no__spin, recursive и metered. (Считаем необходимым разъяснить назначение таких атрибутов, как recursive nmetered: рекурсивные мьютексы позволяют выполнение нескольких повторных блокировок со стороны текущего владельца; мьютексы с регистрирацией фиксируют длину очереди, время ожидания и т.д.) Поскольку еще нет достаточных данных о том, насколько полезны эти атрибуты, в данном томе стандарта IEEE Std 1003.1-2001 они не определены. Однако объекты атрибутов мьютексов позволяют проверить эти идеи на предмет возможной их стандартизации в будущем.

Атрибуты мьютекса и производительность

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

Существует по крайней мере один метод реализации, который можно использовать для сокращения расходов в период блокирования на проверку того, имеет ли мьютекс нестандартные атрибуты. Один такой метод заключается в том, чтобы предварительно заблокировать любые мьютексы, которые инициализированы нестандартными атрибутами. Любая попытка позже заблокировать такой мьютекс заставит реализацию перейти на «медленный путь», как если бы мьютекс был недоступен; затем реализация могла бы «по-настоящему» заблокировать «нестандартный» мьютекс. Базовая операция разблокировки более сложна, поскольку реализация никогда в действительности не желает освобождать мьютекс, который был предварительно заблокирован. Это показывает, что (в зависимости от оборудования) существует необходимость применения оптимизаций для более эффективной обработки часто используемых атрибутов мьютекса.

Использование общей памяти и синхронизация процессов

Существование функций распределения памяти в этом томе стандарта IEEE Std 1003.1-2001 дает приложению возможность выделять память объектам синхронизации из того раздела, который доступен многим процессам (а следовательно, и потокам многих процессов).

Чтобы реализовать такую возможность при эффективной поддержке обычного (т.е. однопроцессорного) случая, был определен атрибут process-shared.

Если реализация по д держивает опцию _POSIX_THREAD_PROCESS_SHARED, то атрибут process-shared м ожно использовать для индикации того, что к мьютексам или условным переменным могут получать доступ потоки сразу нескольких процессов.

Для того чтобы объекты синхронизации по у м олчанию создавались в са м ой эффективной фор м е, для атрибута process-shared в качестве стандартного было выбрано значение PTHREAD_PROCESS_PRIVATE. Пере м енные синхронизации, которые инициализированы значение м PTHREAD_PROCESS_PRIVATE атрибута process-shared, м огут обрабатываться потока м и только в то м процессе, в которо м была выполнена инициализации этих пере м енных. Пере м енные синхронизации, которые инициализированы значение м PTHREAD_PROCESS_SHARED атрибута process-shared, м огут обрабатываться любым потоком в любом процессе, который имеет к ним доступ. В частности, эти процессы могут существовать независимо от процесса инициализации. Например, следующий код реализует простой семафор-счетчик в общедоступном файле, который может быть использован многими процессами.

/* sem.h */

struct semaphore {

pthread_mutex_t lock;

pthread_cond_t nonzero;

unsigned count;

};

typedef struct semaphore semaphore_t;

semaphore_t *semaphore_create (char *semaphore_name);

semaphore_t *semaphore_open (char *semaphore_name);

void semaphore_post (semaphore_t *semap);

void semaphore_wait (semaphore_t *semap); void semaphore_close (semaphore_t *semap);

/* sem.c */

#include <sys/types.h> #include <sys/stat.h> #include <sys/mman.h> #include <fcntl.h> #include <pthread.h> #include 11 sem .h»

semaphore_t *

semaphore_create (char * semaphore_name) t

int fd;

semaphore_t * semap; pthread_mutexattr_t psharedm;

pthread_condattr_t psharedc;

fd = open(semaphore_name, O_RDWR | O_CREAT | O_EXCL, Оббб); if (fd <0)

return (NULL); (void) ftruncate (fd, sizeof (semaphore_t)); (void) pthread_mutexattr_init (&psharedm); (void) pthread_mutexattr_setpshared(&psharedm,

PTHREAD_PROCESS_SHARED) ;

(void) pthread_condattr_init (&psharedc); (void) pthread_condattr_setpshared (&psharedc

PTHREAD_PROCESS_SHARED);

semap = (semaphore_t *) mmap (NULL, sizeof (semaphore_t),

PR0T_READ | PROT_WRITE, MAP_SHARED, fd, О);

close (fd);

(void) pthread_mutex_init (&semap->lock, &psharedm);

(void) pthread_cond_init (&semap->nonzero, &psharedc); semap->count = 0; return (semap);

}

semaphore_t *

semaphore_open (char *semaphore_name) {

int fd;

semaphore_t *semap;

fd = open (semaphore_name, O_RDWR, 0666); if (fd <0)

return (NULL);

semap = (semaphore_t *) mmap (NULL, sizeof (semaphore_t),

PROT_READ | PROT_WRITE, MAP_SHARED, f d, 0) ;

close (fd); return (semap);

}

void

semaphore_post (semaphore_t *semap) {

pthread_mutex_lock (&semap->lock); if (semap->count == 0)

pthread_cond_signal (&semapx->nonzero); semap->count++;

pthread_mutex_unlock (&semap->lock);

}

void

semaphore_wait (semaphore_t * semap) {

pthread_mutex_lock (&semap->lock); while (semap->count == 0)

pthread_cond_wait (&semap->nonzero, &semap->lock); semap->count--;

pthread_mutex_unlock (&semap->lock);

}

void

semaphore_close (semaphore_t *semap) {

munmap ((void *) semap, sizeof (semaphore_t));

}

Следующий код обеспечивает выполнение трех отдельных процессов, которые создают семафор в файле /tmp/semaphore, отправляют сигналы и ожидают его освобождения. После того как семафор создан, программы сигнализации и ожидания инкрементируют и декрементируют счетчик семафора, несмотря на то, что они сами не инициализировали семафор.

/* create.c */

# include «pthread. h»

#include «sem.h»

int main() {

semaphore_t * semap;

semap = semaphore_create («/ tmp/semaphore») ; if (semap == NULL)

exit(l); semaphore_close (semap) ,-return (0);

}

/* post */

# include «pthread. h»

#include «sem.h»

int main() {

semaphore_t *semap;

semap = semaphore_open ("/tmp/semaphore»);

if (semap == NULL)

exit (1);

semaphore_post (semap);

semaphore_close (semap);

return (0);

}

/* wait */

#include «pthread.h»

#include «sem.h» int

main () {

semaphore_t *semap;

semap = semaphore_open ("/tmp/semaphore 11 ); if (semap == NULL)

exit (1); semaphore_wait (semap); semaphore_close (semap); return (0);

}

Будущие направления

Отсутствуют.

Смотри также

pthread_cond_destroy (), pthread_create (), pthread_mutex_destroy (), pthread_mutexattr_destroy (), том Base Definitions стандарта IEEE Std 1003.1-2001,<pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширением POSIX Threads Extension.

Issue 6

Функции pthread_mutexattr_destroy() и pthread_mutexattr_init () отмечены как часть опции Threads.

Раздел «Ошибки» был отредактирован путем при м енения интерпретации IEEE PASC Interpretation 1003.1с #27.

pthread_mutexattr_getprioceiling, pthread_mutexattr_setprioceiling

Имя

pthread_mutexattr_getprioceiling, pthread_mutexattr_setprioceiling

Синопсис

THR #include <pthread.h> TPP

int pthread_mutexattr_getprioceiling (

const pthread_mutexattr_t *restrict attr, int *restrict prioceiling); int pthread_mutexattr_setprioceiling (

pthread_mutexattr_t *attr, int prioceiling);

Описание

Функции pthread_mutexattr_getprioceiling() и pthread_mute-xattr_setprioceiling () используются для считывания и установки соответственно атрибута prioceiling в объекте атрибутов м ьютекса, адресуе м о г о параметром attr, который был ранее создан с помо щ ью функции pthread_mutexattr_init ().

Атрибут prioceiling содержит предельное значение приоритета инициализированных мьютексов. Значения атрибута prioceiling ограничены границами диапазона приоритетов, определенного для стратегии планирования, соответствующей значению SCHED_FIFO.

Значение атрибута prioceiling — это минимальный уровень приоритета, на котором еще выполняется критический раздел, защищаемый мьютексом. Чтобы избежать инверсии приоритетов, предельное значение приоритета мьютекса устанавливается выше самого высокого приоритета всех потоков, которые могут блокировать этот мьютекс, или равным ему.

Возвращаемые значения

При успешно м завершении функции pthread_mutexattr_getprioceiling() и pthread_mutexattr_setprioceiling() возвращают нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функции pthread_mutexattr_getprioceiling () и pthread_mutexattr_setprioceiling () могут завершиться неудачно, если:

[EINVAL] значение, заданное пара м етро м attr, или пара м етро м prioceiling, недействительно;

[EPERM] инициатор вызова не обладает привеле г ия м и для выполнения этой операции.

Эти функции не возвра щ ают код ошибки [EINTR].

pthread_mutexattr_getprioceiling, pthread_mutexattr_setprioceiling — функции считывания и установки атрибута prioceiling в объекте агрибутов м ьютекса (REALTIME THREADS).

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_cond_destroy(), pthread_create(), pthread_mutex_destroy(), том Base Definitions стандарта1ЕЕЕ Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для со г ласования с расширением POSIX Threads Extension.

Отмечены как часть группы Realtime Threads Feature Group.

Issue 6

Функции pthread_mutexattr_getprioceiling() и pthread_mutexattr_setp-rioceiling () отмечены как часть опций Threads и Thread Priority Protection.

Код ошибки [ENOSYS] был исключен, поскольку его нет смысла учитывать, если реализация не под д ерживает опцию Thread Priority Protection.

Ко д ошибки [ENOTSUP] был исключен, поскольку эти функции не имеют аргумента protocol.

В целях согласования со стан д артом ISO/IEC 9899: 1999 в прототип функции pthread_mutexattr_getprioceiling() было д обавлено ключевое слово restrict.

pthread_mutexattr_setprotocol, pthread_mutexattr_getprotocol

Имя

pthread_mutexattr_setprotocol, pthread_mutexattr_getprotocol

Синопсис

THR #include <pthread.h>

TPP|TPI

int pthread_mutexattr_getprotocol (const pthread_mutexattr_t *restrict attr, int *restrict protocol);

int pthread_mutexattr_setprotocol (

pthread_mutexattr_t * attr, int protocol) ;

Описание

Функции pthread_mutexattr_getprotocol() и pthread_mutexattr_setprotocol () используются для считывания и установки соответственно атрибута protocol в объекте атрибутов м ьютекса, адресуе м о г о пара м етро м attr, который был ранее создан с помощью функции pthread_mutexattr_init ().

Параметр protocol определяет протокол, которому необходимо следовать при использовании мьютексов. Этот атрибут может иметь следующие значения (которые определены в заголовке <pthread. h>):

PTHREAD_PRIO_NONE

TPI  PTHREAD_PRIO_INHERIT

TPP  PTHREAD_PRIO_PROTECT

Если поток владеет мьютексом с использованием значения PTHREAD_PRIO_NONE для атрибута protocol, то факт обладания мьютексом не отражается на значении его приоритета и стратегии планирования.

TPI Если поток блокирует потоки с более высоким приоритетом благодаря тому, что он владеет одним или несколькими мьютексами, у которых атрибут protocol и м еет значение PTHREAD_PRIO_INHERIT, то он будет выполняться с наивысши м из приоритетов потоков, ожидаю щ их освобождения любого из м ьютексов.

TPP Если поток владеет одни м или нескольки м и м ьютекса м и, у которых атрибут protocol имеет значение PTHREAD_PRIO_PROTECT, то он будет выполняться с самым высоким из предельных приоритетов всех мьютексов, принадлежащих этому потоку и инициализированных с этим атрибутом, независимо от того, заблокированы другие потоки по любому из этих мьютексов или нет.

Пока поток удерживает м ьютекс, у которого атрибут protocol был инициализирован значение м PTHREAD_PRIO_INHERIT или PTHREAD_PRIO_PROTECT, он не будет претенденто м для пере м ещения в конец очереди планируе м ых заданий в результате из м енения его исходного приоритета, напри м ер, после вызова функции sched_setparam (). Аналогично, если поток разблокирует м ьютекс, у которого атрибут protocol был инициализирован значение м PTHREAD_PRIO_INHERIT или PTHREAD_PRIO_PROTECT, он не будет претенденто м для пере м ещения в конец очереди планируе м ых заданий в результате из м енения его исходного приоритета.

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

TPI Если поток обращается к функции pthread_mutex_lock (), а атрибут protocol задавае м ого м ьютекса был инициализирован значение м PTHREAD_PRIO_INHERIT, и если вызывающий поток блокируется из-за того, что м ьютекс прина д лежит друго м у потоку, то этот поток — владелец м ьютекса — наследует уровень приоритета вызываю щ его потока, приче м до тех пор, пока он продолжает удерживать м ьютекс. Реализация устанавливает приоритет выполнения согласно м акси м ально м у значению (выбранного из заданного и всех унаследованных приоритетов). Более того, если этот поток — владелец м ьютекса са м блокируется по друго м у м ьютексу, такой же эффект наследования приоритетов рекурсивно распространяется и на этого владельца.

Возвращаемые значения

При успешно м завершении функции pthread_mutexattr_getprotocol() и pthread_mutexattr_setprotocol () возвра щ ают нулевое значение; в противно м случае — код ошибки, обозначаю щ ий ее характер.

Ошибки

Функция pthread_mutexattr_setprotocol () завершится неудачно, если:

[ ENOTSUP ] значение, заданное пара м етро м pro tocol , не по д держивается.

Функции pthread_mutexattr_getprotocol() и pthread_mutexattr_setprotocol () м огут завершиться неу д ачно, если:

[EINVAL] значение, заданное пара м етро м attr, или пара м етро м protocol, недействительно;

[EPERM] инициатор вызова не обладает привиле г ия м и для выполнения этой операции.

Эти функции не возвра щ ают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_cond_destroy (), pthread_create (), pthread_mutex_destroy (), то м Base Defmidons стандартаШЕЕ Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширением POSIX Threads Extension.

Отмечены как часть группы Realtime Threads Feature Group.

Issue 6

Функции pthread_mutexattr_getprotocol() и pthread_mutexattr_setprotocol () от м ечены как часть опции Threads и одной из опций Thread Priority Protection или Thread Priority Inheritance.

Код ошибки [ENOSYS] был исключен, поскольку его нет с м ысла учитывать, если реализация не по д держивает опции Thread Priority Protection или Thread Priority Inheritance.

В целях согласования со стан д арто м ISO/IEC 9899:1999 в прототип функции pthread_mutexattr_getprotocol () было д обавлено ключевое слово restrict.

pthread_mutexattr_getpshared, pthread_mutexattr_setpshared

Имя

pthread_mutexattr_getpshared, pthread_mutexattr_setpshared — функ-ции считывания и установки атрибута process-shared.

Синопсис

THR #include <pthread.h> TSH

int pthread_mutexattr_getpshared (

const pthread_mutexattr_t *restrict attr, int *restrict pshared); int pthread_mutexattr_setpshared(

pthread_mutexattr_t *attr, int pshared);

Описание

Функция pthread_mutexattr_getpshared () используется дл я получения значения атрибута process - shared объекта атрибутов, адресуе м о г о пара м етро м attr. Функция pthread_mutexattr_setpshared() позволяет установить атрибут process-shared в инициализированно м объекте атрибутов, адресуе м о м пара м етро м attr.

Атрибут process-shared устанавливается равны м значению PTHREAD_PROCESS_SHARED, чтобы позволить обработку м ьютекса любы м дру г и м потоко м, который и м еет доступ к па м яти, в которой раз м е щ ен этот м ьютекс, даже если он раз м е щ ен в па м яти, сов м естно используе м ой нескольки м и процесса м и. Если атрибут process-shared установлен равны м значению PTHREAD_PROCESS_PRIVATE, м ьютекс будет обрабатываться только теми потоками, созданными в одном процессе с потоком, который инициализировал этот мьютекс; если потоки из различных процессов попытаются работать с таким мьютексом, то дальнейшее их поведение не определено. По умолчанию этот атрибут устанавливается равны м значению PTHREAD_PROCESS_PRIVATE.

Возвращаемые значения

При успешном завершении функция pthread_mutexattr_setpshared() возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

П ри успешно м завершении функция pthread_mutexattr_getpshared() возвра щ ает нулевое значение и сохраняет считанное значение атрибута process-shared объекта attr в объекте, адресуемом параметром pshared, в противном случае возвращается код ошибки, обозначающий ее характер.

Ошибки

Функции pthread_mutexattr_getpshared() и pthread_mutexattr_setpshared () м о г ут завершиться неудачно, если:

[ EINVAL]  значение, заданное параметром attr, недействительно.

Функция pthread_mutexattr_setpshared () м ожет завершиться неу д ачно, если:

[EINVAL] новое значение, за д анное д ля атрибута, попадает вне диапазона значений, действительных д ля этого атрибута.

Эти функции не возвра щ ают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_cond_destroy(), pthread_create(), pthread_mutex_destroy(), pthread_mutexattr_destroy (), то м Base Definidons стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширение м POSIX Threads Extension.

Issue 6

Функции pthread_mutexattr_getpshared() и pthread_mutexattr_setpshared () от м ечены как часть опций Threads и Thread Process-Shared Synchronization.

В целях согласования со стандарто м ISO/IEC 9899: 1999 в прототип функции pthread_mutexattr_getpshared () было добавлено ключевое слово restrict.

pthread_mutexattr_gettype, pthread_mutexattr_settype

Имя

pthread_mutexattr_gettype, pthread_mutexattr_settype — функции считывания и установки атрибута type.

Синопсис

XSI #include <pthread.h>

int pthread_mutexattr_gettype (

const pthread_mutexattr_t *restrict attr, int *restrict type); int pthread_mutexattr_settype (

pthread_mutexattr_t *attr, int type);

Описание

Функции pthread_mutexattr_gettype() и pthread_mutexattr_settype() используются для считывания и установки соответственно атрибута type. Этот атрибут задается при вызове этих функций в пара м етре type. По у м олчанию атрибут type устанавливается равны м значению PTHREAD_MUTEX_DEFAULT.

Атрибут type содержит тип м ьютекса. Допусти м ы м и значения м и атрибута type м огут быть следую щ ие:

PTHREAD_MUTEX_NORMAL

Мьютекс этого типа не обнаруживает взаи м облокировки. Поток, пытаясь перезаблокировать такой м ьютекс без первоначального его разблокирования, попадает во взаи м облокировку. Попытка разблокировать м ьютекс, заблокированный други м потоко м, приводит к неопределенно м у поведению. Попытка разблокировать незаблокированный м ьютекс также приводит к неопределенно м у поведению.

PTHREAD_MUTEX_ERRORCHECK

Мьютекс этого типа выполняет проверку на наличие ошибок. Поток, пытаясь перезаблокировать такой мьютекс без первоначального его разблокирования, генерирует код ошибки. При попытке разблокировать мьютекс, заблокированный другим потоком, генерируется код ошибки. При попытке разблокировать незаблокированный мьютекс также генерируется код ошибки.

PTHREAD_MUTEX_RECURS IVE

П оток, пытаясь перезаблокировать такой мьютекс без первоначального его разблокирования, успешно его блокирует. Взаимоблокировка, возникаю щ ая в результате переблокирования м ьютексов типа PTHREAD_MUTEX_NORMAL, не м ожет произойти с м ьютекса м и этого типа. Множественное блокирование такого м ьютекса потребует такого же количества разблокировок, которые полностью освободят м ьютекс, прежде чем другой поток сможет его захватить. При попытке разблокировать мьютекс, заблокированный другим потоком, генерируется код ошибки. При попытке разблокировать незаблокированный мьютекс также генерируется код ошибки.

PTHREAD_MUTEX_DEFAULT

Попытка рекурсивного блокирования мьютекса этого типа приводит к неопределенному поведению. Попытка разблокировать мьютекс, не заблокированный вызывающим потоком, приводит к неопределенному поведению. Попытка разблокировать незаблокированный мьютекс также приводит к неопределенному поведению. Реализация может преобразовать мьютекс этого типа в один из других типов мьютексов.

Возвращаемые значения

При успешном завершении функция pthread_mutexattr_gettype () возвращает нулевое значение и сохраняет значение атрибута type, считанное из объекта attr, в объекте, адресуемом параметром type; в противном случае она возвращает код ошибки, обозначающий ее характер.

При успешном завершении функция pthread_mutexattr_settype () возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_mutexattr_settype () завершится неудачно, если:

[EINVAL]  значение, заданное пара м етро м type, недействительно.

Функции pthread_mutexattr_gettype () и pthread_mutexattr_settype () могутзавершиться неудачно, если:

[EINVAL]  значение, заданное пара м етро м attr, недействительно.

Эти функции не возвра щ ают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

В приложениях пре д лагалось не использовать м ьютекс типа PTHREAD_MUTEX_RECURSIVE с условны м и пере м енны м и, поскольку неявная блокировка, выполненная д ля функций pthread_cond_timedwait () или pthread_cond_wait (), м ожет в д ействительности не освобо д ить м ьютекс (если он был заблокирован м ногократно). Если это произой д ет, никакой д ругой поток не с м ожет у д овлетворить условию пре д иката.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_cond_timedwait(), том Base Definitions стандарта IEEE Std 1003.1-200l, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Issue 6

Приложен список опечаток Open Group Corrigendum U033/3. Был отредактирован раздел «Синопсис» для функции pthread_mutexattr_gettype (), в результате чего первый аргумент получил тип const pthread_mutexattr_t*.

В целях согласования со стандартом ISO/IEC 9899: 1999 в прототип функции pthread_mutexattr_gettype было добавлено ключевое слово restrict.

pthread_once

Имя

pthread_once — функция д ина м ической инициализации пакетов.

Синопсис

THR #include <pthread.h>

int pthread_once (pthread_once_t *once_control, void (*init_rout_ne) (void)); pthread_once_t once_control = PTHREAD_ONCE_INIT;

Описание

При перво м обра щ ении к функции pthread_once() любы м потоко м процесса с заданны м пара м етро м once_control будет вызвана функция ini t_routine без аргументов. Последующие обра щ ения к функции pthread_once () с те м же пара м етро м once_control не вызывают функцию init_routin e. Возвра щ ение из функции pthread_once() означает, что функция init_routine выполнена. Пара м етр once_control определяет, вызываласьли соответствую щ ал функция инициализации.

Функция pthread_once () не является точкой от м ены. Но если функция init_routine является точкой от м ены, и от м ена таки происходит, то ее воздействие на пара м етр once_control будет таки м, как если бы функция pthread_once () никогда не вызывалась.

Константа PTHREAD_ONCE_INIT определяется в заголовке <pthread. h>.

Поведение функции pthread_once () будет неопределенны м, если пара м етр once_control и м еет авто м атический класс па м яти (объекты этого класса раз м е щ аются в стеке и инициализируются всякий раз при входе в блок, где они объявлены, иразрушаются при выходе из этого блока) или не инициализирован константой PTHREAD_ONCE_INIT.

Возвращаемое значение

При успешно м завершении функция pthread_once () возвра щ ает нулевое значение; в противно м случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_once() м ожет завершиться неудачно, если:

[EINVAL] значения, заданные пара м етра м и once_control или init_routine, недействительны. Функция pthread_once() не возвращает код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Некоторые библиотеки С разработаны для дина м ической инициализации. Это означает, что глобальная инициализация для такой библиотеки выполняется при вызове первой библиотечной процедуры. В однопоточной програ мм е это обычно реализуется с использование м статической пере м енной, значение которой проверяется при входе в функцию, напри м ер:

static int random_is_initialized = 0;

extern int initialize_random ();

int random_function () {

if (random_is_initialized == 0) {

initialize_random ();

random_is_initialized = 1;

}

... /* Операции, выполняемые после инициализации. */

}

Чтобы хранить такую же структуру в многопоточной программе, нужно использовать новый примитив. В противном случае инициализация библиотеки должна быть выполнена путем явного вызова экспортированной функции инициализации до какого бы то ни было использования этой библиотеки.

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

Использование функции pthread_once () не только предоставляет гарантированные реализацией средства дина м ической инициализации, но и способствует надежному функционированию многопоточных систем реального вре м ени. Предыдущий пример с учетом вышесказанного принимает следующий вид.

#include <pthread.h>

static pthread_once_t random_is_initialized =PTHREAD_ONCE_INIT;

extern int initialize_random();

int random_function()

{

(void) pthread_once (&random_is_initialized,initialize_random); ...

/* Операции, выполняемые после инициализации. */

}

Обратите вни м ание на то, что тип pthread_once_t не может быть массивом, поскольку для некоторых компиляторов конструкция &<array_name> неприемлема.

Будущие направления

Отсутствуют.

Смотри также

Том Base Definitions стандарта1ЕЕЕStd 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширением POSIX Threads Extension.

Issue 6

Функция pthread_once () от м ечена как часть опции Threads.

Был добавлен код ошибки [EINVAL], возвращаемый при неудачном завершении функции в случае, если хотя бы один из аргументов недействителен.

pthread_rwlock_destroy, pthread_rwlock_init

Имя

pthread_rwlock_destroy, pthread_rwlock_init — функции разрушения и инициализации объекта блокировки для чтения и записи.

Синопсис

THR

#include <pthread.h>

int pthread_rvlock_destroy(pthread_rwlock_t *rwlock);

int pthread_rwlock_init( pthread_rwlock_t *restrict rwlock, const pthread_rwlockattr_t *restrict attr);

Описание

Функция pthread_rwlock_destroy() используется для разрушения объекта блокировки чтения и записи, адресуемого параметром rwlock, и освобождения любых ресурсов, задействованных этой блокировкой. Результат последующего использования этой блокировки не определен до тех пор, пока объект не будет инициализирован повторно посредство м еще одного обращения к функции pthread_rwlock_init(). В конкретной реализации функция pthread_rwlock_destroy () может устанавливать объект, адресуемый параметром rwlock, равным недействительному значению. Результаты не определены, если функция pthread_rwlock_destroy() вызывается в то вре м я, когда какой-нибудь поток удерживает объект блокировки, адресуе м ый пара м етром rwlock. Попытка разрушить неинициализированный объект блокировки для чтения и записи приводит к неопределенному поведению.

Функция pthread_rwlock_init() выделяет любые ресурсы, необходимые для использования объекта блокировки для чтения и записи, адресуемого пара м етром rwlock, и инициализирует его (он переходит в незаблокированное состояние) с использованием объекта атрибутов, адресуе м ого пара м етро м attr. Если пара м етр attr содержит значение NULL, для блокировки чтения и записи будут использованы атрибуты, действующие по у м олчанию; т.е. результат в это м случае равносилен передаче адреса объекта, содержащего стандартные атрибуты блокировки для чтения и записи. После первой инициализации объект блокировки можно использовать любое число раз без повторной инициализации. Результаты не определены, если функция pthread_rwlock_init () вызвана с заданием уже инициализированного объекта блокировки. Результаты не определены, если объект блокировки для чтения и записи используется без предварительной инициализации.

При неудачном выполнении функции pthread_rwlock_init() объект, адресуемый параметро м rwlock, остается неинициализированны м, а содержимое параметра rwlock — неопределенным.

Для выполнения синхронизации можно использовать только объект, адресуемый параметром rwlock. Результат ссылки на копии этого объекта в вызовах функций pthread_rwlock_destroy(), pthread_rwlock_rdlock(), pthread_rwlock_ti~ medrdlock(), pthread_rwlock_timedwrlock(), pthread_rwlock_tryrdlock(), pthread_rwlock_trywrlock (), pthread_rwlock_unlock () или pthread_rwlock_ wrlock () не опре д елен.

Возвращаемые значения

При успешно м завершении функции pthread_rwlock_destroy() и pthread_rwlock_init () возвра щ ают нулевое значение; в противно м случае — код ошибки, обозначаю щ ий ее характер.

Проверка на наличие ошибок с кода м и [EBUSY] и [EINVAL] реализована (если реализована вооб щ е) так, как будто она выполняется в самом начале работы каждой функции, и код ошибки в случае ее обнаружения возвращается до модификации состояния объекта блокировки чтения и записи, заданного параметром rwlock.

Ошибки

Функция pthread_rwlock_destroy () м ожет завершиться неудачно, если:

[EBUSY]  реализация обнаружила попытку разрушить заблокированный объект, адресуе м ый пара м етро м rwlock;

[EINVAL]  значение, за д анное пара м етро м rwlock, не д ействительно.

Функция pthread_rwlock_init () завершится неу д ачно, если:

[EAGAIN]  систе м а испытывает не д остаток в ресурсах (не и м еется в виду память), необходимых для инициализации еще одного объекта блокировки для чтения и записи;

[ENOMEM]  для инициализации объекта блокировки для чтения и записи недостаточно существующей памяти;

[EPERM]  инициатор вызова не обладает привилегиями для выполнения этой операции.

Функция pthread_rwlock_init () м ожет завершиться неу д ачно, если:

[EBUSY]  реализация обнаружила попытку повторно инициализировать объект блокировки, адресуе м ый пара м етро м rwlock, которой был ранее инициализирован, но еще не разрушен;

[EINVAL]  значение, заданное пара м етро м attr, не д ействительно.

Эти функции не возвращают ко д ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_rwlock_rdlock (), pthread_rwlock_timedrdlock (), pthread_rwlock_timedwrlock (), pthread_rwlock_tryrdlock (), pthread_rwlock_trywrlock(), pthread_rwlock_unlock(), pthread_rwlock_wrlock (), том Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Issue 6

Для согласования со стандартом IEEE Std 1003.1j-2000 были внесены следующие изменения.

• В разделе «Синопсис» изменена метка. Новая метка THR обозначает, что рассматриваемые функции теперь являются частью опции Threads (ранее они относились к опции Read-Write Locks стандарта IEEE Std 1003.1j-2000, а также считались частью дополнения XSI). В раздел «Синопсис» также не входит макрос инициализации.

• Раздел «Описание» отредактирован следующим образом:

— явно отмечено выделение ресурсов при инициализации объекта блокировки для чтения и записи;

— добавлен абзац, в котором указывается, что копии объекта блокировки для чтения и записи использовать нельзя.

• В раздел «Ошибки» добавлен код ошибки [EINVAL] , означающий, что при вызове функции pthread_rwlock_init () значение, заданное пара м етро м attr, было недействительно.

• Отредактирован раздел «Смотри также».

В целях согласования со стандарто м ISO/IEC 9899: 1999 в прототип функции pthread_rwlock_init () было добавлено ключевое слово restrict.

pthread_rwlock_rdlock, pthread_rwlock_tryrdlock

Имя

pthread_rwlock_rdlock, pthread_rwlock_tryrdlock— функции блокирования объекта блокировки чтения-записи для обеспечения чтения.

Синопсис

THR

#include <pthread.h>

int pthread_rwlock_rdlock (pthread_rwlock_t *rwlock) ; int pthread_rwlock_tryrdlock (pthread_rwlock_t *rwlock) ;

Описание

Функция pthread_rwlock_rdlock() при м еняет блокировку для обеспечения чтения к объекгу блокировки чтения-записи, адресуе м о м у пара м етро м rwlock. Вызываю щ ий поток получает блокировку для чте н ия, если никакой записывающий поток не удерживает этот объект блокировки и не существует никаких других записывающих потоков, заблокированных по этому объекту.

TPS Если поддерживается опция Thread Execution Scheduling и потоки, участвующие в данной блокировке, выполняются с использованием стратегий планирования SCHED_FIFO или SCHED_RR, то вызывающий поток не получит эту блокировку, если ее удерживает записывающий поток или если по этому объекту блокировки заблокированы записывающие потоки такого же или более высокого приоритета; в противном случае вызывающий поток получит блокировку.

TSP TSP Если поддерживается опция Thread Execution Scheduling и потоки, участвующие в данной блокировке, выполняются с использованием стратегии планирования SCHED_SPORADIC, то вызывающий поток не получит эту блокировку, если ее удерживает записывающий поток или если по этому объекту блокировки заблокированы записывающие потоки такого же или более высокого приоритета; в противном случае вызывающий поток получит блокировку.

Если опция Thread Execution Scheduling не поддерживается, то только конкретнал реализация определяет, получит ли вызывающий поток эту блокировку, если никакой записывающий поток не удерживает этот объект блокировки и существуют другие записывающие потоки, заблокированные по этому объекту. Если записывающий поток удерживает этот объект блокировки, вызывающий поток не получит блокировку для чтения. Если блокировка для чтения не предоставлена, вызывающий поток блокируется до тех пор, пока он не получит блокировку. Вызывающий поток может попасть в ловушку взаимоблокировки, если во время вызова он удерживает блокировку для обеспечения записи.

Поток м ожет удерживать несколько параллельных блокировок для чтения по объекту rwlock (т.е. функция pthread_rwlock_rdlock () м ожет быть успешно вызвана n раз). В этом случае приложение должно гарантировать, что поток выполнит соответствующие действия по разблокировке объекта rwlock (т.е. он n раз вызовет функцию pthread_rwlock_unlock ()).

Максимальное количество одновременных (и гарантированно успешных) блокировок для чтения, которое может быть применено к объекту блокировки чтения-записи, определяется конкретной реализацией. В случае превышения этого максимума функция pthread_rwlock_rdlock () может завершиться неудачно.

Функция pthread_rwlock_tryrdlock() при м еняет блокировку для обеспечения чтения подобно функции pthread_rwlock_rdlock(), за исключение м того, что эта функция завершится неудачно, если эквивалентный вызов функции pthread_rwlock_rdlock() заблокировал вызывающий поток. Ни в каких случаях функция pthread_rwlock_tryrdlock() не блокирует потоки; она всегда либо добивается блокировки, либо немедленно завершается с неудачным результатом.

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

Возвращаемые значения

При успешном завершении функция pthread_rwlock_rdlock() возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Функция pthread_rwlock_tryrdlock () возвращает нулевое значение, если блокировка для чтения по объекту блокировки чтения-записи, адресуемому параметром rwloc, предоставлена. В противном случае возвращается код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_rwlock_tryrdlock () завершится неудачно, если:

[EBUSY] блокировка чтения-записи не могла быть предоставлена для чтения, поскольку удерживает блокировку записывающий поток, или по этому объекту заблокирован записывающий поток с соответствующим приоритетом .

Функции pthread_rwlock_rdlock() и pthread_rwlock_tryrdlock() м огут завершиться неудачно, если:

[EINVAL] значение, заданное пара м етро м rwlock, не относится к инициализированно м у объекту блокировки чтения-записи;

[EAGAIN] блокировка не м огла быть предоставлена для чтения, поскольку превышено м акси м альное число блокировок чтения по объекту, адресуе м о м у пара м етро м rwlock.

Функция pthread_rwlock_rdlock () м ожет завершиться неудачно, если:

[EDEADLK] теку щ ий поток уже удерживает объект блокировки чтения-записи для обеспечения записи. Эти функции не возвра щ ают код ошибки [EINTR].

Примеры

Отсутствуют.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_rwlock_destroy (), pthread_rwlock_timedrdlock (), pthread_rwlock_timedwrlock (), pthread_rwlock_trywrlock (), pthread_rwlock_unlock (), pthread_rwlock_wrlock (), то м Base Definitions crannapTalEEEStd 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Issue 6

Для согласования со стандарто м IEEE Std 1003.1j-2000 были внесены следую щ ие изменения.

• В разделе «Синопсис» была из м енена м етка. Новая м етка THR означает, что расс м атривае м ые функции теперь являются частью опции Threads (ранее они относились к опции Read-Write Locks стандарта IEEE Std 1003.1j-2000, а также считались частью дополнения XSI).

• Раздел «Описание» был отредактирован следую щ и м образо м:

- заданы условия, при которых записываю щ ие потоки и м еют преи м у щ ество перед считываю щ и м и;

- разъяснена воз м ожная причина неудачного завершения функции pthread_rwlock_tryrdlock();

- добавлен абзац, в которо м говорится о при м енении м акси м ального количество блокировок для обеспечения чтения.

• Был м одифицирован раздел «Ошибки», посвященный описанию кода ошибки [EBUSY] : теперь предлагается принять во внимание приоритет записывающих потоков. Удален абзац, посвященный описанию кода ошибки [EDEADLK] , возвращаемому функцией pthread_rwlock_tryrdlock ().

• Был отредактирован раздел «Смотри также».

Замечания по использованию

Как упо м иналось в то м е Base Definitions стандарта IEEE Std 1003.1-2001 (Se c tion 3.285, Priority Inversion), приложения, которые используют эти функции, м огут подвергнуться инверсии приоритетов.

pthread_rwlock_timedrdlock

Имя

pthread_rwlock_timedrdlock— функция, блокирующал объект блокировки чтения-записи для обеспечения чтения.

Синопсис

THR #include <pthread.h> TMO #include <time.h>

int pthread_rwlock_timedrdlock (

pthread_rwlock_t *restrict rwlock,

const struct timespec *restrict abs_timeout);

Описание

Функция pthread_rwlock_timedrdlock () при м еняет блокировку для обеспечения чтения к объекту блокировки чтения-записи, адресуе м о м у пара м етро м rwlock, подобно функции pthread_rwlock_rdlock (). Однако, если блокировка не может быть предоставлена без ожидания, пока другие потоки не освободят ее, это ожидание будет прервано, когда истечет заданный интервал времени. Интервал времени истекает, когда наступит абсолютное вре м я, заданное пара м етро м abs_timeout (т.е. когда показания вре м ени на используе м ых в систе м е часах станут равны м и или превысят значение abs_timeout), или если абсолютное вре м я, заданное пара м етро м abs_ timeou t, уже наступило в м о м ент вызова.

TMR Если по д держивается опция Timers, отсчет интервала вре м ени происходит с использование м часов CLOCK_REALTIME.

Если опция Timers не поддерживается, отсчет интервала времени происходит с использованием системных часов, значение которых возвращает функция time (). Разрешение для интервала времени определяется разрешением часов, которые используются для его отсчета. Тип данных timespec определяется в заголовке <time.h>. Ни при каких условиях эта функция не завершится неудачно, если блокировка может быть предоставлена немедленно. В проверке достоверности параметра abs_timeout нет никакой необходи м ости, если блокировка м ожет быть предоставлена не м едленно.

Если потоку, заблокированно м у по объекту блокировки чтения-записи при вызове функции pthread_rwlock_timedrdlock(), передается сигнал, то после его обработки поток возобновит ожидание освобождения блокировки, как если бы оно и не прерывалось.

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

Возвращаемое значение

Функция pthread_rwlock_timedrdlock() возвра щ ает нулевое значение, если блокировка для чтения по объекту блокировки чтения-записи, адресуе м о м у пара м етро м rwloc, предоставлена. В противно м случае возвращается код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_rwlock_timedrdlock () завершится неудачно, если:

[ETIMEDOUT] блокировка не м огла быть предоставлена до истечения за д анного интервала вре м ени.

Функция pthread_rwlock_timedrdlock () м ожет завершиться неу д ачно, если:

[EAGAIN]  блокировка д ля чтения не м огла быть пре д оставлена, поскольку

превышено м акси м альное число блокировок чтения по объекгу, адресуемому пара м етро м rwlock

[EDEADLK]  вызываю щ ий поток уже у д ерживает объект блокировки для обеспечения записи по объекту, адресуемому параметром rwlockr,

[EINVAL]  значение, заданное параметром rwlock, не относится к инициализированному объекту блокировки чтения-записи, или значение abs_timeout, выраженное в наносекундах, меньше нуля либо больше или равно 1000 миллионам.

Эта функция не возвращает код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Как упо м иналось в то м е Base Definitions стан д арта IEEE Std 1003.1-2001 (Section 3.285, Priority Inversion), приложения, которые используют эту функцию, могут по д вергнуться инверсии приоритетов.

Функция pthread_rwlock_timedrdlock() является частью опций Threads и Timeouts и может быть не пре д оставлена во всех реализациях.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_rwlock_destroy(), pthread_rwlock_rdlock(), pthread_rwlock_timedwrlock(), pthread_rwlock_tryrdlock(), pthread_rwlock_trywrlock(), pthread_rwlock_unlock(), pthread_rwlock_wrlock (), то м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>, <time.h>.

Последовательность внесения изменений

Функция впервые реализована в выпуске Issue 6, основание м послужил стандарт IEEEStd 1003.1j-2000.

pthread_rwlock_timedwrlock

Имя

pthread_rwlock_timedwrlock — функция, блокирующая объект блокировки чтения-записи для обеспечения записи.

Синопсис

THR TMO

#include <pthread.h>

#include <time.h>

int pthread_rwlock_timedwrlock (

pthread_rwlock_t *restrict rwlock,

const struct timespec *restrict abs_timeout);

Описание

Функция pthread_rwlock_timedwrlock () при м еняет блокировку для обеспечения записи к объекту блокировки чтения-записи, адресуемому пара м етро м rwlock, подобно функции pthread_rwlock_wrlock (). Однако, если блокировка не м ожет быть предоставлена без ожидания, пока другие потоки не освободят ее, это ожидание будет прервано, когда истечет заданный интервал вре м ени. Интервал вре м ени истекает, когда наступит абсолютное вре м я, заданное пара м етро м abs_timeout (т.е. когда показания времени на используемых в системе часах станут равными или превысят значение abs_timeout), или если абсолютное вре м я, заданное пара м етро м abs_timeout, уже наступило в момент вызова.

TMR Если поддерживается опция Timers, отсчет интервала вре м ени происходит с использование м часов CLOCK_REALTIME.

Если опция Timers не поддерживается, отсчет интервала времени происходит с использованием системных часов, значение которых возвращает функция time (). Разрешение для интервала времени определяется разрешением часов, которые используются для его отсчета. Тип данных timespec определяется в заголовке <time.h>. Ни при каких условиях эта функция не завершится неудачно, если блокировка может быть предоставлена немедленно. В проверке достоверности параметра abs_timeout нет никакой необходимости, если блокировка может быть предоставлена немедленно.

Если потоку, заблокированно м у по объекту блокировки чтения-записи при вызове функции pthread_rwlock_timedwrlock(), передается сигнал, то после его обработки поток возобновит ожидание освобождения блокировки, как если бы оно и не прерывалось.

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

Возвращаемое значение

Функция pthread_rwlock_timedwrlock () возвра щ ает нулевое значение, если блокировка для записи по объекту блокировки чтения-записи, адресуе м о м у пара м етро м rwloc, предоставлена. В противно м случае возвращается код ошибки, обозначающий ее характер.

Ошибки

Фу н кция pthread_rwlock_timedwrlock () завершится неудачно, если:

[ETIMEDOUT] блокировка не м огла быть предоставлена до истечения заданного интервала вре м ени.

Функция pthread_rwlock_timedwrlock () м ожет завершиться неудачно, если:

[EDEADLK]  вызываю щ ий поток уже удерживает объект блокировки по объекту,

адресуе м о м у пара м етро м rwlock;

[EINVAL]  значение, заданное пара м етро м rwlock, не относится к инициализированно м у объекту блокировки чтения-записи, или значение abs_timeout, выраженное в наносекундах, меньше нуля либо больше или равно 1000 миллионам.

Эта функция не возвра щ ает код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Как упоминалось в томе Base Definitions стандарта IEEE Std 1003.1-2001 (Section 3.285, Priority Inversion), приложения, которые используют эту функцию, могут подвергнуться инверсии приоритетов.

Функция pthread_rwlock_timedwrlock() является частью опций Threads и Timeouts и может быть не предоставлена во всех реализациях.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_rwlock_destroy(),pthread_rwlock_rdlock(), pthread_rwlock_timedrdlock(), pthread_rwlock_tryrdlock(), pthread_rwlock_trywrlock (), pthread_rwlock_unlock (), pthread_rwlock_wrlock (), том Base Definitions стандарта IEEE Std 1003.1-2001, <pthread. h>, <t ime. h>.

Последовательность внесения изменений

Функция впервые реализована в выпуске Issue 6, основание м послужил стандарт IEEEStd 1003.1j-2000.

pthread_rwlock_trywrlock, pthread_rwlock_wrlock

Имя

pthread_rwlock_trywrlock, pthread_rwlock_wrlock — функции, блокирующие объект блокировки чтения-записи для обеспечения записи.

Синопсис

THR

#include <pthread.h>

int pthread_rwlock_trywrlock (pthread_rwlock_t *rwlock);

int pthread_rwlock_wrlock (pthread_rwlock_t *rwlock);

Описание

Функция pthread_rwlock_trywrlock () при м еняет блокировку для обеспечения записи подобно функции pthread_rwlock_wrlock(), за исключением того, что эта функция завершится неудачно, если какой-нибудь поток в данный момент удерживает блокировку по объекту, адресуемому пара м етро м rwlock (для чтения или записи).

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

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

Возвращаемые значения

Функция pthread_rwlock_trywrlock() возвра щ ает нулевое значение, если блокировка для записи по объекту блокировки чтения-записи, адресуе м о м у пара м етро м rwloc, предоставлена. В противно м случае возвра щ ается код ошибки, обозначаю щ ий ее характер.

При успешном завершении функция pthread_rwlock_wrlock () возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_rwlock_trywrlock () завершится неудачно, если:

[EBUSY] блокировка чтения-записи не м огла быть предоставлена для записи, поскольку заданный объект блокировки уже заблокирован для чтения или записи.

Функции pthread_rwlock_wrlock() и pthread_rwlock_trywrlock() м огут завершиться неудачно, если:

[EINVAL] значение, заданное пара м етро м rwlock, не относится к инициализированно м у объекту блокировки чтения-записи.

Функция pthread_rwlock_wrlock () м ожет завершиться неудачно, если:

[EDEADLK] теку щ ий поток уже удерживает объект блокировки чтения-записи для обеспечения записи или чтения.

Эти функции не возвра щ ают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Как упо м иналось в то м е Base Definitions стандарта IEEE Std 1003.1-2001 (Section 3.285, Priority Inversion), приложения, которые используют эти функции, м огут подвергнуться инверсии приоритетов.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_rwlock_destroy(),pthread_rwlock_rdlock(), pthread_rwlock_timedrdlock (), pthread_rwlock_timedwrlock (), pthread_rwlock_tryrdlock(),pthread_rwlock_unlock(), том Base Definitions cтaндapтaIEEEStd 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в вылуске Issue 5.

Issue 6

Для согласования со стандарто м IEEE Std 1003.1j-2000 были внесены следующие изменения:

• В разделе «Синопсис» была из м енена м етка. Новал м етка THR означает, что расс м атривае м ые функции теперь являются частью опции Threads (ранее они от-

носились к опции Read-Write Locks стандарта IEEE Std 1003.1j-2000, а также считались частью дополнения XSI).

• Из раздела «Ошибки» удален абзац, посвященный описанию кода ошибки [EDEADLK] , возвращаемому функцией pthread_rwlock_trywrlock ().

• Был отредактирован раздел «С м отри также».

pthread_rwlock_unlock

Имя

pthread_rwlock_unlock— функция разблокирования объекта блокировки чтения-записи.

Синопсис

THR

#include <pthread.h>

int pthread_rwlock_unlock(pthread_rwlock_t *rwlock);

Описание

Функция pthread_rwlock_unlock () используется для освобождения блокировки, удерживае м ой с по м о щ ью объекта блокировки чтения-записи, адресуе м ого параметро м rwlock. Результаты не определены, если объект блокировки чтения-записи, адресуе м ый пара м етро м rwlock, не удерживается вызывающим потоком.

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

Если эта функция вызывается, чтобы освободить блокировку для обеспечения записи по заданному объекту блокировки чтения-записи, то этот объект перейдет в разблокированное состояние.

Если существуют потоки, заблокированные по этому объекту блокировки, то при его освобождении именно стратегия планирования определяет, какой поток (потоки) получит блокировку.

TPS Если потоки, ожидающие освобождения блокировки, выполняются в соответствии со стратегиями планирования SCHED_FIFO, SCHED_RR или SCHED_SPORADIC, то при поддержке опции Thread Execution Scheduling после освобождения этой блокировки потоки получат блокировку в порядке следования их приоритетов. Для потоков с одинаковыми приоритетами блокировки для записи имеют преимущество перед блокировками для чтения.

Если опция Thread Execution Scheduling не поддерживается, то будут ли блокировки для записи иметь преимущество перед блокировками для чтения, определяется конкретной реализацией.

Результаты не определены, если эта функция вызывается с неинициализированным объектом блокировки чтения-записи.

Возвращаемое значение

При успешном завершении функция pthread_rwlock_unlock () возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_rwlock_unlock () м ожет завершиться неудачно, если:

[EINVAL] значение, заданное пара м етро м rwlock, не относится к инициализированно м у объекту блокировки чтения-записи

[EPERM] текущий поток не удерживает объект блокировки чтения-записи для обеспечения записи или чтения.

Функция pthread_rwlock_unlock () не возвра щ ает код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_rwlock_destroy(), pthread_rwlock_rdlock(), pthread_rwlock_timedrdlock (), pthread_rwlock_timedwrlock (), pthread_rwlock_tryrdlock(), pthread_rwlock_trywrlock(), pthread_rwlock_wrlock (), то м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в вылуске Issue 5. Issue 6

Для согласования со стандартом IEEE Std 1003.1j-2000 были внесены следующие изменения.

• В разделе «Синопсис» была изменена метка. Новал метка THR означает, что рассматриваемые функции теперь являются частью опции Threads (ранее они

относились к опции Read-Write Locks стандарта IEEE Std 1003.1j-2000, а также считались частью дополнения XSI).

• Раздел «Описание» был отредактирован следующим образом:

— заданы условия, при которых записывающие потоки имеют преимущество перед считывающими;

— удалена концепция владельца блокировки чтения-записи.

• Был отредактирован раздел «Смотри также».

pthread_rwlockattr_destroy, pthread_rwlockattr_init

Имя

pthread_rwlockattr_destroy, pthread_rwlockattr_init— функции разрушения и инициализации объекта атрибутов для блокировки чтения-записи.

Синопсис

THR #include <pthread.h>

int pthread_rwlockattr_destroy(

pthread_rwlockattr_t *attr); int pthread_rwlockattr_init(pthread_rwlockattr_t *attr);

Описание

Функция pthread_rwlockattr_destroy() используется для разрушения объекта атрибутов для блокировки чтения-записи. Разрушенный объект атрибутов, адресуемый параметром attr, можно инициализировать повторно с помощью функции pthread_rwlockattr_init (); результаты ссылки на этот объект после его разрушения не определены. В конкретной реализации функция pthread_rwlockattr_destroy() может устанавливать объект, адресуемый параметром attr, равным недействительному значению.

Функция pthread_rwlockattr_init () предназначена для инициализации объекта атрибутов блокировки чтения-записи attr значением, действующим по умолчанию для всех атрибутов, определенных конкретной реализацией.

Если функция pthread_rwlockattr_init () вызывается для уже инициализированного объекта атрибутов attr, то результаты вызова этой функции не определены.

После того как объект атрибутов блокировки чтения-записи уже был использован для инициализации одной или нескольких блокировок чтения-записи, Любая функция, которая оказывает влияние на объект атрибутов (включал деструктор), никак не отразится на ранее инициализированных блокировках чтения-записи.

Возвращаемые значения

При успешно м завершении функции pthread_rwlockattr_destroy() и pthread_rwlockattr_init() возвращают нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_rwlockattr_destroy () может завершиться неудачно, если:

[EINVAL]  значение, заданное параметром attr, недействительно.

Функция pthread_rwlockattr_init () завершится неудачно, если:

[ENOMEM]  для инициализации объекта атрибутов блокировки чтения-записи недостаточно существующей памяти.

Эти функции не возвращают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_rwlock_destroy(), pthread_rwlockattr_getpshared(), pthread_rwlockattr_setpshared (), то м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5.

Issue 6

Для согласования со стандартом IEEE Std 1003.1j-2000 были внесены следующие изменения.

• В разделе «Синопсис» была изменена метка. Новал метка THR означает, что рассматриваемые функции теперь являются частью опции Threads (ранее они относились к опции Read-Write Locks стандарта IEEE Std 1003.1j-2000, а также считались частью дополнения XSI).

• Был отредактирован раздел «Смотри также».

pthread_rwlockattr_getpshared, pthread_rwlockattr_setpshared

Имя

pthread_rwlockattr_getpshared, pthread_rwlockattr_setpshared —функции считывания и установки атрибута process-shared в объекте атрибутов блокировки чтения-записи.

Синопсис

THRTSH #include <pthread.h>

int pthread_rwlockattr_getpshared(

const pthread_rwlockattr_t *restrict attr, int *restrict pshared) ; int pthread_rwlockattr_setpshared(

pthread_rwlockattr_t * attr, int pshared);

Описание

Функция pthread_rwlockattr_getpshared() используется для получения значения атрибута process-shared из инициализированного объекта атрибутов, адресуе м ого пара м етро м attr. Функция pthread_rwlockattr_setpshared () позволяет установить атрибут process-shared в инициализированно м объекте атрибутов, адресуе м о м пара м етро м attr.

Атрибут process-sharedycтанaвливaeтcя равны м значению PTHREAD_PROCESS_ SHARED, чтобы разрешить использование объекта блокировки чтения-записи любы м потоко м, и м ею щ и м доступ к области па м яти, в которой он раз м е щ ен, даже если эта область па м яти разделяется нескольки м и процесса м и. Если же атрибут process-shared равен значению PTHREAD_PROCESS_PRIVATE, объект блокировки чтения-записи должен использоваться только потока м и, созданны м и в одно м процессе с потоко м, который его инициализировал; если с эти м объекто м блокировки чтения-записи попытаются работать потоки из различных процессов, поведение такой програ мм ы не определено. По у м олчанию для этого атрибута устанавливается значение PTHREAD_PROCESS_PRIVATE.

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

Возвращаемые значения

При успешно м завершении функция pthread_rwlockattr_getpshared() возвра щ ает нулевое значение и сохраняет считанное значение атрибута process-shared объекта attr в объекте, адресуе м о м пара м етро м pshared\ в противно м случае возвра щ ается код ошибки, обозначающий ее характер.

При успешно м завершении функция pthread_rwlockattr_setpshared() возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функции pthread_rwlockattr_getpshared() и pthread_rwlockattr_ setpshared () м огут завершиться неудачно, если:

[ EINVAL ] значение, заданное пара м етро м attr, недействительно.

Функция pthread_rwlockattr_setpshared () м ожетзавершиться неудачно, если:

[EINVAL] новое значение, заданное для атрибута, попа д ает вне д иапазона значений, д ействительных д ля этого атрибута.

Эти функции не возвра щ ают ко д ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_rwlock_destroy(),pthread_rwlockattr_destroy(), pthread_rwlockattr_init (), то м Base Definitions стан д арта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5.

Issue 6

Для согласования со стан д арто м IEEE Std 1003.1j-2000 были внесены сле д ую щ ие из м енения.

• В разделе «Синопсис» была изменена метка. Новая метка THR означает, что расс м атривае м ые функции теперь являются частью опции Threads (ранее они относились к опции Read-Write Locks стан д арта IEEE Std 1003.1j-2000, а также считались частью д ополнения XSI).

• В разделе «Описание» отмечено, что дополнительные атрибуты определяются конкретной реализацией.

• Был отредактирован раздел «Смотри также».

В целях согласования со стандартом ISO/IEC 9899: 1999 в прототип функции pthread_rwlockattr_getpshared () было добавлено ключевое слово restrict.

pthread_self

Имя

pthread_self — функция получения и д ентификационного но м ера (ID) вызывающего потока.

Синопсис

THR #include <pthread.h>

pthread_t pthread_self {void);

Описание

Функция pthread_self() возвра щ ает и д ентификационный но м ер (ID) вызываю щ его потока.

Возвращаемое значение

См. раз д ел «Описание».

Ошибки

Ко д ы ошибок не опре д елены.

Функция pthread_self () не возвра щ ает ко д ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Функция pthread_self() обеспечивает воз м ожность, аналогичную функции getpid () д ля процессов, поэто м у и логическое обоснование у нее такое же: при вызове функции соз д ания потока и д ентификационный но м ер (ID) соз д анно м у потоку авто м атически не пре д оставляется.

Будущие направления

Отсутствуют.

Смотри также

pthread_create (), pthread_equal (), то м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функция впервые реализована в выпуске Issue 5. Включена для согласования с расширение м POSIX Threads Extension.

Issue 6

Функция pthread_self () от м ечена как часть опции Threads.

pthread_setcancelstate, pthread_setcanceltype, pthread_testcancel

Имя

pthread_setcancelstate, pthread_setcanceltype, pthread_testcancel— функции установки состояния от м ены (аннулирования) потока.

Синопсис

THR #include <pthread.h>

int pthread_setcancelstate(int state, int *oldstate);

int pthread_setcanceltype(int type, int *oldtype);

void pthread_testcancel(void);

Описание

Функция pthread_setcancelstate() о д новре м енно устанавливает состояние от м ены вызываю щ его потока равны м значению, за д анно м у пара м етро м state, и возвра щ ает значение предыдущего состояния от м ены в пере м енной, а д ресуе м ой пара м етро м oldstate. Допусти м ы м и значения м и д ля пара м етра state являются PTHREAD_CANCEL_ENABLE и PTHREAD_CANCEL_DISABLE.

Функция pthread_setcanceltype () о д новре м енно устанавливает тип от м ены вызываю щ его потока равны м значению, за д анно м у пара м етро м type, и возвра щ ает значение предыдущего типа от м ены в пере м енной, а д ресуе м ой пара м етро м oldtype. Допусти м ы м и значения м и д ля пара м етра type являются PTHREAD_CANCEL_ DEFERRED и PTHREAD_CANCEL_ASYNCHRONOUS.

Состояние и тип отмены любых создаваемых потоков, включал поток, в которо м впервые вызывается функция main(), устанавливаются равны м и значения м PTHREAD_CANCEL_ENABLE и PTHREAD_CANCEL_DEFERRED соответственно.

Функция pthread_testcancel () пре д назначена д ля соз д ания точки от м ены в вызываю щ е м потоке. Функция pthread_testcancel () не и м еет эффекта, если от м ена потока запре щ ена.

Возвращаемые значения

При успешно м завершении функции pthread_setcancelstate() и pthread_ setcanceltype () возвра щ ают нулевое значение; в противно м случае возвра щ ается ко д ошибки, обозначаю щ ий ее характер.

Ошибки

Функция pthread_setcancelstate () м ожет завершиться неу д ачно, если:

[EINVAL] за д анный пара м етр state не со д ержит ни значения PTHREAD_ CANCEL_ENABLE , низначения PTHREAD_CANCEL_DI SABLE.

Функция pthread_setcanceltype () м ожет завершиться неу д ачно, если:

[EINVAL] за д анный пара м етр type не со д ержит ни значения PTHREAD_ CANCEL_DEFERRED, ни значения PTHREAD_CANCEL_ASYNCHRONOUS.

Эти функции не возвра щ ают ко д ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Функции pthread_setcancelstate () и pthread_setcanceltype () позволяют управлять точка м и, в которых поток можно асинхронно отменить. Для того чтобы управление отменой потоков можно было осуществлять в соответствии с модульными принципами, необходимо следовать следующим правилам.

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

Во-первых, на входе в объект возможность отмены должна быть запрещена (никогда явно не разрешена). На выходе из объекта состояние отмены должно быть всегда восстановлено до значения, которое оно имело на входе в этот объект.

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

Во-вторых, на входе в объект тип отмены можно установить явным образом (равным либо «отложенному», либо «асинхронному» значению). Но, как и для состояния отмены, на выходе из объекта тип отмены должен быть всегда восстановлен до значения, которое он имел на входе в этот объект.

Наконец, из потока, который позволяет асинхронную от м ену, м ожно вызывать только безопасные (с точки зрения от м ены) функции.

Будущие направления

Отсутствуют.

Смотри также

pthread_cancel(), то м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширение м POSIX Threads Extension.

Issue 6

Функции pthread_setcancelstate (), pthread_setcanceltype () и pthread_ testcancel () от м ечены как часть опции Threads.

pthread_setschedprio

Имя

pthread_setschedprio — функция д ина м ического д оступа к пара м етра м планирования потока (REALTIME THREADS).

Синопсис

THRTPS #include <pthread.h>

int pthread_setschedprio(pthread_t thread, int prio);

Описание

Функция pthread_setschedprio () используется д ля установки приоритета планирования равны м значению, заданно м у пара м етро м prio, для потока, идентификационный но м ер (ID) которого задан пара м етро м thread.

В случае неудачного завершения функции pthread_setschedprio () приоритет планирования заданного потока останется без из м енения.

Возвращаемое значение

При успешно м завершении функция pthread_setschedprio () возвра щ ает нулевое значение; в противно м случае возвра щ ается код ошибки, обозначаю щ ий ее характер.

Ошибки

Функция pthread_setschedprio () м ожет завершиться неудачно, если:

[EINVAL] значение пара м етра prio не действительно для стратегии планирования заданного потока;

[ENOTSUP] была сделана попытка установить приоритет равны м значению, которое не поддерживается;

[EPERM] инициатор вызова не и м еет соответствую щ его разрешения на установку пара м етров стратегии планирования за д анного потока;

[EPERM] реализация не позволяет приложению м о д ифицировать приоритет, устанавливая его равны м за д анно м у значению;

[ESRCH] значение, за д анное пара м етро м thread, не относится к су щ ествую щ е м у потоку.

Функция pthread_setschedprio () не возвра щ ает ко д ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Функция pthread_setschedprio() обеспечивает для приложения воз м ожность вре м енно г о увеличения приоритета с последую щ и м ero понижение м без нежелательного побочного эффекта, выражае м ого в установке други м и потока м и такого же приоритета. Это нужно, если приложение должно реализовать такие собственные стратегии для ограничения инверсии приоритетов, как наследование приоритетов или использование предельных значений приоритетов. Эта воз м ожность особенно важна, если реализация не по д держивает опции Thread Priority Protection или Thread Priority Inheritance, но даже в случае их по д держки эту воз м ожность необходи м о использовать, если приложение обязано привязывать наследование приоритетов к использованию таких ресурсов, как се м афоры.

Нес м отря на то что, воз м ожно, предпочтительнее было бы решить эту пробле м у, м одифицируя спецификацию функции pthread_setschedparam(), было слишко м поздно вносить такое из м енение, поскольку уже су щ ествовали реализации, которые пришлось бы в это м случае из м енять. Поэто м у даннал функция и была введена.

Будущие направления

Отсутствуют.

Смотри также

pthread_getschedparam(), то м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread. h>.

Последовательность внесения изменений

Функция впервые реализована в выпуске Issue 6. Включена в качестве реакции на интерпретацию IEEE PASC Interpretation 1003.1 #96.

СПИСОК ЛИТЕРАТУРЫ

1. Audi, Robert. Action, Intention, andReason. Ithaca, N. Y.: Cornell University Press, 1993.

2. Axford, Tom. Concurrent Programming: Fundamental Techniques for Real-Time and ParalMSoftwareDesign, Chichester, U. K.:JohnWiley, 1989.

3. Baase, Sarah. ComputerAlgorithms: Introduction to Design andAnalysis. 2nd ed. Reading, Mass.:Addison-Wesley, 1988.

4. Barfield, Woodrow, and Thomas A. Furnell III. Virtual Environments and Advanced InterfaceDesign. New York: Oxford University Press, 1995.

5. Binkley, Robert, Bronaugh, Richard, and Ausonio Marras. Agent, Action, andReason. Toronto: UniversityofToronto Press, 1971.

6. Booch, Grady, James Rumbaugh, and IvarJacobson. The Unified Modeling Language UserGuide. Boston: Addison-Wesley, 1999.

7. Bowan, Howard, andJohn Derrick. FormalMethods forDistributedProcessing: A Survey of Object-OrientedApproaches. NewYork: Cambridge University Press, 2001.

8. Brewka, Gerhard,Jurgen Diz, and Kurt Konolige. Nonmonotonic Reasoning. Stanford, Calif.: CSLI Publications, 1997.

9. Carroll, Martin D., and Margaret A. Ellis. Designing and CodingReusabh C++. Reading, Mass.: Addison-Wesley, 1995.

10. Cassell, Justine, Joseph Sullivan, Scott Prevost, and Elizabeth Churchill. Embodied ConversationalAgents. Cambridge, Mass.: MIT Press, 2000.

11. Chellas, Brian F. ModalLogic: An Introduction. New York: Cambridge University Press, 1980.

12. Coplien,James O. MuUi-Paradigm Design for C++. Reading, Mass.: Addison-Wesley, 1999.

13. Cormen, Thomas, Charles Leiserson, and Ronald Rivet. Introduction to Algorithms. Cambridge, Mass.: MIT Press, 1995.

14. Englemore, Robert, and Tony Morgan. BUickboard Systems. Wokingham, England: Addison-Wesley, 1988.

15. Garg, Vijay K. Principhs ofDistnbutedSystems. Norwell, Mass.: KluwerAcademic, 1996.

16. Geist, A1, Adam Beguelin, Jack Dongarra, Weicheng Jiang, Robert Manchek, and VaidySinderman. PVM:ParaUelVirtualMachine. London, England: MITPress, 1994.

17. Goodheart, Berny, andJames Cox. The Magic Garden ExpUiined: The Internak of Unix System VReUase4. New York: Prentice Hall, 1994.

18. Gropp, William, Steven Huss-Lederman, Andrew Lumsdaine, Ewing Lusk, Bill Nitzberg, William Saphir, and Marc Snir. MPI: The Compkte Reference. Vol. 2. Cambridge, Mass.: MIT Press, 1998.

19. Heath, Michael T. Scientific Computing: An Introduction Survey. New York: McGraw-Hill.

20. Henning, Michi, and Steve Vinoski. Advanced COBRA Programming with C++. Reading, Mass.: Addison-Wesley, 1999.

21. Hintikka,Jakko, and Merrill Hintikka. The Logic ofEpistemoU>gy and the EpistemoU>gy of LogTC.Amsterdam: KluwerAcademic, 1989.

22. Horty,John F. Agency andDeonticLogic. New York: Oxford University Press, 2001.

23. Hughes, Cameron, and Tracey Hughes. Mastering the Standard C++ CJmses. New York: JohnWiley, 1990.

24. Hughes, Cameron, and Tracey Hughes. Object-OrientedMuUithreading Using C++. New York:JohnWiley, 1997.

25. Hughes, Cameron, and Tracey Hughes. Linux Rapid Application Devebpment. Foster City, Calif.: M & T Books, 2000.

26. International Standard Organization. Information Technobgy: Portabk Operating System Interface. Pt. 1 System Application Program Interface. 2nd ed. Std 1003.1 ANSI/IEEE. 1996.

27. Josuttis, Nicolai M. The C++ Standard Boston: Addison-Wesley, 1999.

28. Koeing, Andrew, and Barbara Moo. Ruminations on C++. Reading, Mass.: Addison-Wesley, 1997.

29. Krishnamoorthy, C. S., and S. Rajeev. Artificial Intelligence and Expert Systems for Engineers. Boca Raton, Fla.: CRC Press, 1996.

30. Lewis, Ted, Glenn Andert, Paul Calder, Erich Gamma, Wolfgang Press, Larcy Rosenstein, and Kraus, Sarit. Strategic Negotiation in MuUitangent Environments. London: МГГ Press, 2001.

31. Luger, George F. ArtificialInteUigence. 4th ed. England: Addison-Wesley, 2002.

32. Mandrioli Dino, and Carlo Ghezzi. Theoretical Foundations of Computer Science. New York:JohnWiley, 1987.

33. Nielsen, Michael A., and Isaac L. Chuang. Quantum Computation and Quantum Information. New York: Cambridge University Press, 2000.

34. Patel, Mukesh J., Vasant Honavar, and Karthik Balakrishnan. Advances in the Evolutionary SynthesisofIntelligentAgents. Cambridge, Mass.: МГГ Press, 2001.

35. Picard, Rosalind. Affective Computing. London: MIT Press, 1997.

36. Rescher, Nicholas, and Alasdir Urquhart. Temporal Logic. New York: Springer-Verlag, 1971.

37. Robbins, Kay A., and Steven Robbins. Practical Unix Programming. Upper Saddle River, N.J.: Prentice Hall, 1996.

38. Schmucker, Kurt, Ander Weinand, andJohn M. VUssides. Object-OrientedApplication Frameworks. Greenwich, Conn.: ManningPublications, 1995.

39. Singh, Наггу. Progressing to Distributed Multiprocessing. Upper Saddle River, N.J.: Prentice Hall, 1999.

40. Skillicorn, David. Foundations of ParaUel Programming. New York: Cambridge University Press, 1994.

41. Soukup, Jiri. Taming C++: Pattern Ckisses and Persistence for Large Projects. Reading, Mass.:Addison-Wesley, 1994.

42. Sterling, Thomas L.,John Salmon, DonaldJ. Becker, and Daniel F. Savarese. How to Build a Bewoulf: A Guide to ImpUmentation and Application of PC Clusters. London: MITPress, 1999.

43. Stevens, Richard W. UNIX Network Programming: Interprocess Communications. Vol. 2, 2nd ed. Upper Saddle River: Prentice Hall, 1999.

44. Stroustrup, Bjarne. TheDesign andEvohUion of C++. Reading, Mass.: Addison-Wesley, 1994.

45. Subrahmanian, V.S., Piero Bonatti,Jurgen Dix, Thomas Eiter, Sarit Kraus, Fatma Ozcan, and Robert Ross. HeterogeneousAgentSystems. Cambridge, Mass.: МГГ Press, 2000.

46. Tel, Gerard. Introduction to Distributed Algorithms. 2nd ed. New York: Cambridge University Press, 2000.

47. Thompson, WilliamJ. ComputingforScientists andEngineers. New York:John Wiley, 1992.

48. Tomas, Gerald, and Christoph W. Uebeerhuber. Visualization of Scientific ParaUel Programming. New York: Springer-Verlag, 1994.

49. Tracy, Kim W. and Peter Bouthoorn. Object-Oriented: Artificial InteVigence Using C++. NewYork: ComputerScience Press, 1997.

50. Weiss, Gerhard. MultitagentSystems. Cambridge, Mass.: MFTPress, 1999.

51. Wooldridge, Michael. ReasoningAboutRationalAgents. London: MIT Press, 2000.

Notes

1

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

2

IEEE— профессиональное объединение, выпускающие свои собственные стандарты; членами IEEE являются ANSI и ISO.

3

) В оригинале написано «On the other hand, the distributed application in Figure 1-1 consists of three separate programs with each program executing on a separate computer». Что можно перевести как «С другой стороны, распределенное приложение на рисунке 1-1 состоит из трех отдельных программ, каждая из которых выполняется на отдельном компьютере» (Примечание пирата)

4

M.J. Flynn. Very high-speed computers. Из сборников объединения IEEE, 54, 1901-1909 (декабрь 1966).

5

MPP- Massively Parallel Processors (процессоры с массовым параллелизмом), SMP- symmetric multi-processor(симметричный мультипроцессор).

6

В оригинале «text segment», что принято переводить как «сегмент кода»

7

В оригинале - «Some hardware resources are preempted to allow different processes access»

8

В оригинале - «Therefore, once the thread exits, its resources, namely thread id, can be instantly reused» Exist & exits — все-таки разные слова

9

В оригинале следующее - «If the terminating thread did not make a call to pthread_exit(), then the exit status will be the return value of the function, if it has one; otherwise, the exit status is NULL» Под функцией в данном случае подразумевается функция, составляющая тело потока.

10

коду ошибки, на самом деле

11

Не макроса, а инициализации предопределенной константой, вообще-то

12

Правда, это не обеспечивает автоматически того, что исключение не будет возбуждено какой-либо функцией, вызванной данным методом.

13

Мы не включаем многопоточные программы в категорию распределенных

14

Все примеры использования CORBA-компонентов в этой книге реализованы с использованием версии MICO 2.3.3 в операционной системе SuSE Linux и версии MICO 2.3.7 в операционной системе Solaris 8.

15

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

16

wCorba - это стандарт CORBA для беспроводного взаимодействия удаленных объектов. Материалы по стандарту wCORBA доступны по адресу: www.omg.org.

17

Все МРI- примеры в этой книге реализованы с использованием версий MPICH 1.1.2 и MPICH 1.2.4 в среде Linux.

18

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

19

При использовании термина объект в определении агента мы включаем родственные для него понятия из области искусственного интеллекта: исполнитель и фрейм.

20

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

21

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

22

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

23

На практике каждый сегмент источника знаний должен содержать один или несколько стандартных контейнерных С++-классов, используемых в качестве очередей данных и очередей событий. Безопасность каждого контейнера обеспечивается за счет компонентов синхронизации.

24

Эта конфигурация обусловлена тем, что Prolog имеет множество таких встроенных средств, как операция унификации, возврат к предыдущему состоянию и поддержка логики предикатов, которые в противном случае (без использования языка Prolog) пришлось бы реализовать в С++ «с нуля». В этой книге для примеров, в которых мы «смешиваем» С++ с языком Prolog, используется версия SWI-Prolog (разработка университета в Амстердаме) и ее С++ библиотека интерфейсов.

25

Для всех CORBA-примеров этой книги мы использовали реализацию Mico 2.3.3 в среде Linux и Mico 2.3.7 в ОС Solaris 8.

26

Дословный перевод man pages

27

Точнее — это единственный член, который должен быть установлен обязательно

Content

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

Введение

Этапы большого пути

Подход

Почему именно С++

Библиотеки для параллельного и распределенного программирования

Новый единый стандарт спецификаций UNIX

Для кого написана эта книга

Среды разработки

Дополнительный материал

Диаграммы UML

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

Параграфы

Тестирование кода и его надежность

Ждем ваших отзывов!

Благодарности

Преимущества параллельного программирования

Что такое параллелизм

Два основных подхода к достижению параллельности

Преимущества параллельного программирования

Простейшая модель параллельного программирования (PRAM)

Простейшая классификация схем параллелизма

Преимущества распределенного программирования

Простейшие модели распределенного программирования

Мультиагентные распределенные системы

Минимальные требования

Декомпозиция

Связь

Синхронизация

Базовые уровни программного параллелизма

Параллелизм на уровне инструкций

Параллелизм на уровне подпрограмм

Параллелизм на уровне объектов

Параллелизм на уровне приложений

Отсутствие языковой поддержки параллелизма в С++

Варианты реализации параллелизма с помощью С++

Стандарт MPI

PVM: стандарт для кластерного программирования

Стандарт CORBA

Реализации библиотек на основе стандартов

Среды для параллельного и распределенного программирования

Резюме

Проблемы параллельного и распределенного программирования

Кардинальное изменение парадигмы

Проблемы координации

Проблема № 1 : «гонка» данных

Проблема № 2: бесконечная отсрочка

Проблема №3: взаимоблокировка

Проблема №4: трудности организации связи

Отказы оборудования и поведение ПО

Негативные последствия излишнего параллелизма и распределения

Выбор архитектуры

Различные методы тестирования и отладки

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

Резюме

Разбиение С++ программ на множество задач

Определение процесса

Два вида процессов

Блок управления процессами

Анатомия процесса

Состояния процессов

Планирование процессов

Стратегия планирования

Использование утилиты ps

Установка и получение приоритета процесса

Переключение контекста

Создание процесса

Отношения между родительскими и сыновними процессами

Утилита pstree

Использование системной функции fork()

Использование семейства системных функций exec

Функции execl ()

Функции execv ()

Определение ограничений для функций exec ()

Чтение и установка переменных среды

Использование POSIX-функций для порождения процессов

Идентификация родительских и сыновних процессов с помощью функций управления процессами

Завершение процесса

Функции exit (), kill () и abort ()

Ресурсы процессов

Типы ресурсов

POSIX-функции для установки ограничений доступа к ресурсам

Асинхронные и синхронные процессы

Создание синхронных и асинхронных процессов с помощью функций fork (), exec (), system () и posix_spawn()

Функция wait ()

Разбиение программы на задачи

Линии видимого контура

Резюме

Разбиение C++ программ на множество потоков

Определение потока

Контекстные требования потока

Сравнение потоков и процессов

Различия между потоками и процессами

Потоки, управляющие другими потоками

Преимущества использования потоков

Переключение контекста при низкой (ограниченной) доступности процессора

Возможности повышения производительности приложения

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

Упрощение структуры программы

Недостатки использования потоков

Потоки могут легко разрушить адресное пространство процесса

Один поток может ликвидировать целую программу

Потоки не могут многократно использоваться другими программами

Анатомия потока

Атрибуты потока

Планирование потоков

Состояния потоков

Планирование потоков и область конкуренции

Стратегия планирования и приоритет

Изменение приоритета потоков

Ресурсы потоков

Модели создания и функционирования потоков

Модель делегирования

Модель с равноправными узлами

Модель конвейера

Модель «изготовитель-потребитель»

Модели SPMD и МРМD для потоков

Введение в библиотеку Pthread

Анатомия простой многопоточной программы

Компиляция и компоновка многопоточных программ

Создание потоков

Получение идентификатора потока

Присоединение потоков

Создание открепленных потоков

Использование объекта атрибутов

Создание открепленных потоков с помощью объекта атрибутов

Управление потоками

Завершение потоков

Точки аннулирования потоков

Очистка перед завершением

Управление стеком потока

Установка атрибутов планирования и свойств потоков

Установка области конкуренции потока

Использование функции sysconf ()

Управление критическими разделами

Безопасность использования потоков и библиотек

Разбиение программы на несколько потоков

Использование модели делегирования

Использование модели сети с равноправными узлами

Использование модели конвейера

Использование модели «изготовитель-потребитель»

Создание многопоточных объектов

Резюме

Синхронизация параллельно выполняемых задач

Координация порядка выполнения потоков

Взаимоотношения между синхронизируемыми задачами

Отношения типа старт-старт (CC)

Отношения типа финиш-старт (ФС)

Отношения типа старт-финиш (СФ)

Отношения типа финиш-финиш (ФФ)

Синхронизация доступа к данным

Модель РРАМ

Параллельный и исключающий доступ к памяти

Что такое семафоры

Операции по управлению семафором

Мьютексные семафоры

Использование мьютексного атрибутного объекта

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

Блокировки для чтения и записи

Использование блокировок чтения-записи для реализации стратегии доступа

Условные переменные

Использование условных переменных для управления отношениями синхронизации

Объектно-ориентированный подход к синхронизации

Резюме

Объединение возможностей параллельного программирования и C++ средств на основе PVM

Классические модели параллелизма, поддерживаемые системой PVM

Библиотека PVM для языка С++

Компиляция и компоновка C++/PVM-npoгpaмм

Выполнение PVM-программы в виде двоичного файла

Запуск PVM-программ c помощью PVM-консоли

Запуск PVM-программ c помощью XPVM

Требования к PVM-программам

Объединение динамической С++-библиотеки c библиотекой PVM

Методы использования PVM-задач

Реализация модели SPMD (SIMD) c помощью PVM-и С++-средств

Реализация модели MPMD (MIMD) с помощью PVM-и С++-средств

Базовые механизмы PVM

Функции управления процессами

Упаковка и отправка сообщений

Доступ к стандартному входному потоку (stdin) и стандартному выходному потоку (stdout) со стороны PVM-задач

Получение доступа к стандартному выходному потоку (cout) из сыновней задачи

Резюме

Обработка ошибок, исключительных ситуаций и надежность программного обеспечения

Надежность программного обеспечения

Отказы в программных и аппаратных компонентах

Определение дефектов в зависимости от спецификаций ПО

Обработка ошибок или обработка исключительных ситуаций?

Надежность ПО: простой план

План А: модель возобновления, план Б: модель завершения

Использование объектов отображения для обработки ошибок

Механизмы обработки исключительных ситуаций в С++

Классы исключений

Классы runtime__error

Классы logic_error

Выведение новых классов исключений

Защита классов исключений от исключительныхситуаций

Диаграммы событий, логические выражения и логические схемы

Резюме

Распределенное объектно-ориентированное программирование

Декомпозиция задачи и инкапсуляция ее решения

Взаимодействие между распределенными объектами

Синхронизация взаимодействия локальных и удаленных объектов

Обработка ошибок и исключений в распределенной среде

Доступ к объектам из других адресных пространств

. IOR-доступ к удаленным объектам

Брокеры объектных запросов (ORB)

Язык описания интерфейсов (IDL):более «пристальный» взгляд на CORBA-объекты

Анатомия базовой CORBA-программы потребителя

Анатомия базовой CORBA-программы изготовителя

Базовый npoeкт CORBA-приложения

IDL-компилятор

Получение IOR-ссылки для удаленных объектов

Служба имен

Использование службы имен и создание именных контекстов

Служба имен «потребитель-клиент»

Подробнее об объектных адаптерах

Хранилища реализаций и интерфейсов

Простые pacnpeделенные Web-службы, использующие CORBA-спецификацию

Маклерская служба

Парадигма «клиент-сервер»

Резюме

Реализация моделей SPMD и MPMD с помощью шаблонов и MPI-программирования

Декомпозиция работ для MPI-интерфейса

Дифференциация задач по рангу

Группирование задач по коммуникаторам

Анатомия MPI-задачи

Использование шаблонных функций для представления MPI-задач

Реализация шаблонов и модельБРМО (типы данных)

Использование полиморфизмадля реализации MPMD-модели

Введение MPMD-модели c помощью функций -объектов

Как упростить взаимодействие между MPI-задачами

Перегрузка операторов «<<» и «>>» для организации взаимодействия между MPI-задачами

Резюме

Визуализация проектов параллельных и распределенных систем

Визуализация структур

Классы и объекты

Отображение информации об атрибутах и операциях класса

Организация атрибутов и операций

Шаблонные классы

Отношения между классами и объектами

Интерфейсные классы

Организация интерактивных объектов

Отображение параллельного поведения

Сотрудничество объектов

Процессы и потоки

Отображение нескольких потоков выполнения и взаимодействия между ними

Последовательность передачи сообщений между объектами

Деятельность объектов

Конечные автоматы

Параллельные подсостояния

Распределенные объекты

Визуализация всей системы

Визуализация развертывания систем

Архитектура системы

Резюме

Проектирование компонентов для поддержки параллелизма

Как воспользоваться преимуществами интерфейсных классов

Подробнее об объектно-ориентированном взаимном исключении и интерфейсных классах

«Полуширокие» интерфейсы

Поддержка потокового представления

Перегрузка операторов "«" и "»" для PVM-потоков данных

Пользовательские классы, создаваемые для обработки PVM-потоков данных

Объектно-ориентированные каналы и FIFO-очереди как базовые элементы низкого уровня

Связь каналов c iostream-объектами с помощью дескрипторов файлов

Доступ к анонимным каналам c использованием итератора ostream_iterator

FIFO-очереди (именованные каналы),

Интерфейсные FIFO-классы

Каркасные классы

Резюме

Реализация агентно-ориентированных архитектур

Что такое агенты

Агенты: исходное определение

Типы агентов

В чем состоит разница между объектами и агентами

Понятие об агентно-ориентированном программировании

Роль агентов в распределенном программировании

Агенты и параллельное программирование

Базовые компоненты агентов

Когнитивные структуры данных

Методы рассуждений

Реализация агентов в С++

Типы данных предположений и структуры убеждений

Класс агента

Цикл активизации агента

Простая автономность

12.6. Резюме

Реализация технологии «классной доски» с использованием PVM-средств, потоков и компонентов

Модель «классной доски»

Методы структурирования «классной доски»

Анатомия источника знаний

Стратегии управления для «классной доски»

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

Пример использования CORBA-объекта «классной доски»

Реализация интерфейсного класса black_board

Порождение источников знаний в конструкторе «классной доски»

Порождение источников знаний с помощью PVM-задач

Связь «классной доски» и источников знаний

Активизация источников знаний с помощью POSIX-функции spawn()

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

Активизация источников знаний с помощью потоков

Резюме

Приложение A

Диаграммы классов и объектов

Диаграммы взаимодейс т вия

Диаграммы сотрудничества

Диаграммы последовательностей

A.2.3. Диаграммы видов деятельности

A.3. Диаграммы состояний

A.4. Диаграммы пакетов

Приложение Б

posix_spawn, posix_spawnp

posix_spawn_file_actions_addclose, posix_spawn_file_actions_addopen

posix_spawn_file_actions_adddup2

posix_spawn_file_actions_destroy, posix_spawn_file_actions_init

posix_spawnattr_destroy, posix_spawnattr_init

posix_spawnattr_getflags, posix_spawnattr_setflags

posix_spawnattr_getpgroup, posix_spawnattr_setpgroup

posix_spawnattr_getschedparam, posix_spawnattr_setschedparam

posix_spawnattr_getschedpolicy, posix_spawnattr_setschedpolicy

posix_spawnattr_getsigdefault, posix_spawnattr_setsigdefault

posix_spawnattr_getsigmask, posix_spawnattr_setsigmask

pthread_attr_destroy, pthread_attr_init

pthread_attr_getdetachstate, pthread_attr__setdetachstate

pthread_attr_getguardsize, pthread_attr_setguardsize

pthread_attr_getinheritsched, pthread_attr_setinheritsched

pthread_attr_getschedparam, pthread_attr_setschedparam

pthread_attr_getschedpolicy, pthread_attr_setschedpolicy

pthread_cancel

pthread_cleanup_pop, pthread_cleanup_push

pthread_cond_broadcast(),pthread_cond_signal()

pthread_cond_destroy, pthread_cond_init

pthread_cond_timedwait, pthread_cond_wait

pthread_condattr_destroy, pthread_condattr_init

pthread_condattr_getpshared, pthread_condattr_setpshared

pthread_create

pthread_detach

pthread_exit

pthread_getconcurrency, pthread_setconcurrency

pthread_getschedparam, pthread_setschedparam

pthread_join

pthread_mutex_destroy, pthread_mutex_init

pthread_mutex_getprioceiling, pthread_mutex_setprioceiling

pthread_mutex_lock, pthread_mutex_trylock, pthread_mutex_unlock

pthread_mutex_timedlock

pthread_mutexattr_destroy

pthread_mutexattr_getprioceiling, pthread_mutexattr_setprioceiling

pthread_mutexattr_setprotocol, pthread_mutexattr_getprotocol

pthread_mutexattr_getpshared, pthread_mutexattr_setpshared

pthread_mutexattr_gettype, pthread_mutexattr_settype

pthread_once

pthread_rwlock_destroy, pthread_rwlock_init

pthread_rwlock_rdlock, pthread_rwlock_tryrdlock

pthread_rwlock_timedrdlock

pthread_rwlock_timedwrlock

pthread_rwlock_trywrlock, pthread_rwlock_wrlock

pthread_rwlock_unlock

pthread_rwlockattr_destroy, pthread_rwlockattr_init

pthread_rwlockattr_getpshared, pthread_rwlockattr_setpshared

pthread_self

pthread_setcancelstate, pthread_setcanceltype, pthread_testcancel

pthread_setschedprio

Notes