Диаграммы UML

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

 

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

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

 

Параграфы

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

 

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

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

 

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

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

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

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

E-mail: 

WWW: 

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

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

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

 

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

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

 

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

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

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

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

 

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

 

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

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

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

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

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

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

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

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

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

 

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

PRAM — это способ построения простой модели, которая позволяет представить, как компьютеры можно условно разбить на процессоры и память и как эти процессоры получают доступ к памяти. Упрощенная классификации схем функционирования параллельных компьютеров была предложена M. Флинном (M.J. Flynn) . Согласно этой классификации различались две схемы: 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) • Этот вид параллелизма обычно поддерживается директивами компилятора и не попадает под управление С++-программиста.

 

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

ДСС структуру программы можно представить в виде ряда функций, т.е. сумма работ, из которых состоит программное решение, разбивается на некоторое количество функций. Если эти функции распределить по потокам, то каждую функцию в этом случае можно выполнить на отдельном процессоре, и, если в вашем распоряжении будет достаточно процессоров, то все функции смогут выполняться одновременно. Подробнее потоки описываются в главе 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) ;

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

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

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++-разработчик в случае необходимости выбирает другие библиотеки, соответствующие новому сценарию работы.

 

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

Задача А получает запросы от задачи В на выполнение операций снятия денег со счета. Задача А также получает запросы от задачи С положить деньги на депозит. За-Дача А принимает запросы и обрабатывает их по принципу «первым пришел — первым обслужен». Предположим, на счете имеется 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, а задачи В и С «скованы» взаимоблокировкой, то те другие задачи будут ожидать условия, которое никогда не выполнится. При координации параллельно выполняемых задач необходимо помнить, что взаимоблокировка и бесконечная отсрочка — это самые опасные преграды, которые нужно предусмотреть и избежать.

 

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

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

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

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

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

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

• сокеты;

• семафоры.

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

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

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

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

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

 

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

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

 

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

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

 

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

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

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

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

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

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

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

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

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

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

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

 

Если готовых к выполнению процессов больше одного, планировщик должен определить, какой из них первым назначить процессору. С этой целью планировщик поддерживает структуры данных, которые позволяют наиболее эффективным образом распределять между процессами процессорное время. Каждый процесс получает класс (тип) приоритета и размещается в соответствующей очереди вместе с другими работоспособными процессами того же приоритетного класса. Поэтому существует несколько приоритетных очередей, которые представляют различные классы приоритетов, используемые системой. Эти приоритетные очереди упорядочиваются и помещаются в массив распределения, именуемый также многоуровневой приоритетной очередью (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 int nice(int incr);

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

Синопсис

#include

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

//...

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

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

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

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

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

int system(const char *string);

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

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

 

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

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

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

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

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

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

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

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

Синопсис

#include

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

#include

#include

#include

{

//...

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

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

void exit(int status);

void abort(void) ;

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

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

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

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

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

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

Синопсис

#include

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-архивом, мониторы, клавиатуры, звуковые, сетевые и графические карты, а также модемы. Все эти устройства могут совместно использовать несколько процессов.

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

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

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

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

 

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

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

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

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

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

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

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

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

Синопсис

#include

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 можно присвоить любые значения, а также символические константы, определенные в заголовке .

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

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 <

В листинге 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

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 определяет, как должно происходить ожидание процесса, и может принимать одно из значений следующих констант, определенных в заголовке :

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

#include

#include

#include

#include

#include

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

#include

#include

#include

#include

#include

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, объект может создавать любое количество процессов из любого метода.

 

Под потоком подразумевается часть выполняемого кода в 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 потока) немедленно принимаются на повторное использование. Для установки и считывания значений этих атрибутов предусмотрены специальные методы. После создания потока его атрибуты нельзя изменить до тех пор, пока он существует.

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

Таблица 4.3. Члены объекта атрибутов потока

Атрибут 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.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 — один поток выполнения, несколько потоков данных). Эта модель описывает систему с одним потоком выполнения, который обрабатывает различные наборы, или потоки, данных. Это означает, что различные наборы данных обрабатываются несколькими идентичными потоками выполнения (вызывающими одну и ту же подпрограмму).

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

 

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

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

// простой многопоточной программе

#include

#include

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() заставляет основной поток ожидать до тех пор, пока все рабочие потоки завершатся и «присоединятся» к основному.

 

Компиляция и компоновка многопоточных программ

Все многопоточные программы, использующие библиотеку потоков 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

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

#include

#include

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

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

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

с++ -о program4-12 program4-12.cc -lpthread

Среда для тестирования SuSE Linux 7.1, gcc 2.95.2,

Инструкции по выполнению ./program4-12 34

Примечания Эта программа требует задания аргумента командной строки.

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

 

Получение идентификатора потока

Как упоминалось выше, процесс разделяет все свои ресурсы с потоками, используя лишь собственное адресное пространство. Потокам в собственное пользование выделяются весьма небольшие их объемы. Идентификатор потока (id) — это один из ресурсов, уникальных для каждого потока. Чтобы узнать свой идентификатор, потоку необходимо вызвать функцию pthread_self ().

Синопсис

#include

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

int pthread_join(pthread_t thread, void **value_ptr);

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

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

 

Создание открепленных потоков

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

Синопсис

#include

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

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

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. Воз можна ситуация, когда одному потоку необходимо завершить другой поток в том же процессе. Например, приложение может иметь поток, который контролирует работу других потоков. Если окажется, что некоторый поток «плохо себя ведет», или больше не нужен, то ради экономии системных ресурсов, возможно, его нужно завершить. Завершающийся поток может окончиться немедленно или отложить завершение до тех пор, пока не достигнет в своем выполнении некоторой логической точки. При этом вполне вероятно, что такой поток (прежде чем завершиться) должен выполнить некоторые действия очистительно-восстановительного характера. Поток имеет также возможность отказаться от завершения.

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

Синопсис

#include

int pthread_exit(void *value_ptr);

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

Для отмены выполнения некоторого потока по инициативе потока из того же адресного пространства используется функция pthread__cancel (). Отменяемый поток задается параметром thread.

Синопсис

#include

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

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

void pthread_testcancel(void)

Программа 4.3 содержит функции, которые вызывают функции pthread_setcancelstate(), pthread_setcanceltype() и pthread_testcancel(), связанные с установкой типа аннулирования потока и состояния готовности к аннулированию.

#include

#include

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

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

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

с++ -о 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

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

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

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

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

#include

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

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

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

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

#include

Параметр 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. Системные переменные и соответствующие им символьные константы

 

Управление критическими разделами

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

Если существуют процессы или потоки, которые получают доступ к разделяемым модифицируемым данным, структурам данных или переменным, то все эти данные находятся в критической области (или разделе) кода процессов или потоков. Критический раздел кода — это та его часть, в которой обеспечивается доступ потока или процесса к разделяемому блоку модифицируемой памяти и обработка соответствующих данных. Отнесение раздела кода к критическому можно использовать для управления состоянием «гонок». Например, создаваемые в программе два потока, поток А и поток В, используются для поиска нескольких ключевых слов во всех файлах системы. Поток А просматривает текстовые файлы в каждом каталоге и записывает нужные пути в списочную структуру данных 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(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 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

2 #include

3 #include

4 #include

5 #include

6 #include

7 #include

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 TextFiles;

17 set >KeyWords;

18 set >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.

 

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

• делегирование («управляющий-рабочий»");

• сеть с равноправными узлами;

• конвейер;

• «изготовитель-потребитель».

Каждая модель характеризуется собственной декомпозицией работ (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

#include

#include

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.

 

Предположим, у нас есть три параллельно выполняющихся потока — А, В и С. Все они участвуют в обработке списка. Список необходимо отсортировать, выполнить в нем операции поиска и вывода результатов. Каждому потоку назначается отдельная задача. Так, поток А должен отобразить результаты поиска, В — отсортировать список, а С — провести поиск. Сначала список необходимо отсортировать, затем выполнить несколько параллельных операций поиска, а уж потом отобразить результаты. Если задачи, выполняемые потоками, не синхронизировать надлежащим образом, то поток А может попытаться отобразить еще не сгенерированные результаты, что нарушит постусловие, или выхо д ное условие (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 — самая трудная для реализации стратегия, которая требует максимальной синхронизации.

#img_29.png Рис. 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

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;

Этот метод менее затратный, но в нем не предусмотрено проверки ошибок.

Мьютекс может иметь или не иметь владельца. Операция запроса на монопольное использование предоставляет право владения мьютексом вызывающему потоку или процессу. После того как мьютекс обрел владельца, поток (или процесс) получает монопольный доступ к запрашиваемому ресурсу. При попытке завладеть «уже занятым» мьютексом (путем вызова этой операции), совершенной любыми другими потоками или процессами, они будут заблокированы до тех пор, пока мьютекс не станет доступным. При освобождении мьютекса следующий (по очереди) поток или процесс (который был заблокирован) деблокируется и получает право собственности на этот мьютекс. И освободить его может только поток, получивший данный мьютекс во владение с помощью функции 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- и СФ-отношения синхронизации невозможно реализовать подобным образом. Эти методы используются для синхронизации пор я дка выполнени я процессов.

 

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

• Управление процессами.

• Упаковка сооб щ ений и их отправка.

• Распаковка сооб щ ений и их прием.

• Обмен задач сигналами.

• Управление буферо м сооб щ ений.

• Функции обработки инфор м ации и служебные процедуры.

• Групповые операции.

Эти библиотечные функции легко интегрировать в С++ среду. Префикс pvm_ в имени каждой функции позволяет не забыть о ее принадлежности соответствующему пространству имен. Для использования PVM-функций необходимо включить в программу заголовочный файл pvm3 . h и скомпоновать ее с библиотекой libpvm. В программах 6.1 и 6.2 демонстрируется, как работает простая PVM-программа. Инструкции по компиляции и выполнению программы 6.1 приведены в разделе «Профиль програ мм ы 6.1».

// Программа 6.1

#include «pvm3.h» #include #include

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

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

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

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>

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

ф^У--о-^годгат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-б иблиотека.

Переменная среды 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-среды

6.2. Библио т ека PVM для языка С++ 221

Окончание табл. 6.2

Параграф 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 () содержит идентификатор задачи-получате л я.

#img_32.png Рис. 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) объектов. Программа pvm_generic_combination «не знает», что она будет работать с двумя типами данных. В листин г е 6.6 представлен раздел кода из программы pvm_generic_combination.

// Листинг 6.6. Использование тега MessageId для //   распознания типов данных

pvm_bufinfo (N, &NumBytes, &MessageId, &Ptid) ; if(MessageId == 1){

vector 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(Source, Ptid,Value); delete Buf;

}

if(MessageId == 2){

vector 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(Source, Ptid,Value); delete ImportantNumber;

}

Здесь используется тег MessageId, позволяю щ ий распознать, с каким типом данных м ы работае м. Но в С++ воз м ожно более удачное решение. Если тег MessageId содержит число 1, значит, м ы работае м со строка м и. Следовательно, м ожно сделать сле-лую щ ее объявление: vector Source;

Если тег MessageId содержит число 2, то м ы знае м, что должны работать с числа м и с плаваю щ ей точкой, и поэто м уделае м такое объявление: vector 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-демона (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 () с л едует испо л ьзовать то л ько в случае, когда сооб щ ение уже отправлено и в буфере нет никакой необходимости.

 

Среда 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.

 

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

• Вариант1. Завершить программу.

• Вариант 2. Возвратить значение, обозначающее «ошибку».

• Вариант 3. Возвратить значение, обозначающее нормальное завершение, и оставить программу в состоянии с необработанной ошибкой.

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

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

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

 

План А: модель возобновления, план Б: модель завершения

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

 

В идеале во время тестирования и отладки должны быть ликвидированы все дефекты протраммы или по крайней мере максимально возможное их количество. Кроме того, следует обработать нежелательные и неудобные условия с использованием обычной программной логики. После устранения всех (или почти всех) дефектов и обработки нежелательных и неудобных условий все остальные «неприятности» попадают в разряд исключительных ситуаций. Обработка исключительных ситуаций в С++ по д держивается с помощью трех ключевых слов: 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= () и конструкторы класса обработки исключений).

#img_36.png Рис. 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.

#img_37.png Рис. 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() -методов. Пустые аргументы означают, что данный метод не может сгенерировать исключение . Если он попытается это сделать, во время компиляции будет выдано сообщение об ошибке. Если базовый класс не может сгенерировать исключение, то соответствующий метод в любом производном классе также не сделает этого.

 

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

Декомпозиция (decomposition) — это процесс разделения задачи и ее решения на ряд подзадач, коллекций объектов и принципов взаимоотношений между этими объектами. Аналогично инкапсуляция (encapsulation) — это моделирование характеристик, атрибутов и поведения некоторого лица, места, предмета или идеи с помощью С++-конструкции class. Такое моделирование (инкапсуляция) и декомпозиция являются частью этапа проектирования объектно-ориентированного ПО. Объектно-ориентированные приложения, которые содержат распределенные объекты, вносят в процесс проектирования дополнительный уровень сложности. С точки зрения «чистого» проектирования местоположение объектов в приложении не должно влиять на разработку атрибутов и характеристик этих объектов. Класс — это модель и, если местоположение не является частью этой модели, то даже самое «крайнее» расположение объектов (экземпляров этого класса) не должно иметь значение. Однако объекты существуют не в вакууме. Они взаимодействуют и обмениваются информацией с другими объектами. Если объекты (участники взаимодействия) расположены на разных компьютерах, и, возможно, даже в различных сетях, то оказывается, что фактор местоположения объектов необходимо с самого начала включать в процесс проектирования ПО. И хотя насчет того, на каком именно этапе проектирования следует рассматривать этот фактор, специалисты существенно расходятся во мнениях, тем не менее все единолушны в том, что его необходимо рассматривать. Дело в том, что обработка ошибок и исключений при взаимодействии объектов, расположенных в различных процессах или на различных компьютерах, отличается от обработки ошибок и исключений при взаимодействии объектов одного и того же процесса. Кроме того, связи и взаимодействия между объектами одного процесса реализуются совершенно не так, как при расположении объектов в различных процессах, которые могут выполняться на разных компьютерах. Это нужно иметь в виду еще на раннем этапе проектирования. В распределенном объектно-ориентированном приложении вся его работа делится между объектами и реализуется в виде функций-членов различных объектов. Объекты должны быть логически разделены согласно определенной модели декомпозиции работ (Work Breakdown Model — WBM). Они могут быть разделены согласно моделям типа «клиентс - сервер», «изготовитель-потребитель», равноправных узлов, «классной доски» или мультиагентной системы. Логическая структура каждой такой модели (с особенностями распределения объектов) показана на рис. 8.1.

Во всех моделях, показанных на рис. 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 — открытую реализацию спецификации 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-ссылки:

Рис. 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

4 #include

5 #include 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) этот объект используется как любой другой объект С++. И хотя существуют весьма значительные различия между вызовами локальных и удаленных объектов , объектно-ориентированное представление, тем не менее, поддерживается, и с точки зрения объектно-ориентированного программирования удаленные объекты ведут себя как локальные. Код, представленный в программе 8.1, является кодом клиентской части приложения (или кодом «потребителя»), поскольку в нем используются возможности объекта adding_machine. Поэтому теперь (для получения завершенного приложения калькулятора) нам нужен код «ответной части», который реализует объект adding_machine. Код этого второго компонента представлен в программе 8.2.

// Программа 8.2

1 #include

2 #include

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, представл я ют собой зарезервированные слова, используемые в 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-компилятор создаст из определения интерфейса С++-код, реализация методов интерфейсного класса остается все еще неопределенной. 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 *_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. Использование наследования для создания пото м ков из одного из нескольких каркасных классов и реализация м етодов интерфейса, унаследованных от каркасных классов.

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

 

Итак, из программ, представленных на рис. 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».

 

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  Опреде ля ет макрос препроцессора. Эта опци я эквивалентна ключу -D у большинства UNIX С-компиляторов

• -I  Определяет путь поиска для директив #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 , стандарт беспроводной спецификации CORBA, который можно использовать для улучшения мобиль-ности объектов. Эта беспроводнал спецификация позволяет реализовать связь посредством MIOR-ссылки (Mobile IOR). Она поддерживается для TCP-, UDP- и WAP WDP-механизмов передачи (Wireless Application Protocol Wireless Datagram Protocol). Мультиагентные и распределенные агентные системы также могут воспользоваться преимуществами стандартов IOR-ссылок. IOR- и MIOR-ссылки являются частью «строительных блоков» слелующего поколения объектно-ориентированных Web-служб. Важно отметить, что хотя строковые IOR-ссылки обеспечивают гибкость и переносимость, они не могут идеально подходить ко всем ситуациям и конфигурациям. Передача файла, который содержит IOR-ссылку, — не слишком приемлемое требование для многих систем. Трудно с точки зрения практичности требовать от приложений клиента и сервера разделять одну и ту же файловую систему или сеть. А с точки зрения безопасности строковый вариант IOR-ссылки вообще исключается как достойный рассмотрения. Если приложение типа «клиент-сервер» велико по объему и достаточно разнотипно, то требование разделения строковой формы IOR

 

Стандарт службы имен обеспечивает механизм преобразовани я имен в объектные ссылки. Автор запроса на 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

2 #include

3 #include «permutation_impl.h»

4 #define MICO_CONF_IMR

5 #include

6 #include

7 #include

8 #include

9 #include 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, мы понимаем, что 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-служб.

 

Одним из преимуществ использования MPI-интерфейса перед традиционными UNIX/Linux-процессами и сокетами является способность MPI-среды запускать одновременно несколько выполняемых файлов. MPI-реализация может запустить несколько выполняемых файлов, установить между ними базовые отношения и идентифицировать каждый выполняемый файл. В этой книге мы используем MPICH-реализацию MPI-интерфейса 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. Функции, используемыедля работы с коммуникаторами

 

Анатомия 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 функций (подробная информация представлена в соответствующей документации).

 

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

template T multiplies(T X, T Y) {

return( X * Y);

}

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

//. . .

multiplies(3.2,4.5);

multiplies(7, 2) ; multiplies(«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(3.2,4.6); break;

case 2: multiplies(X,Y)

break; //case n:

//.. .

}

}

Поскольку не существует двух задач с одинаковым ранго м, все ветви в инструкции case листинга 9.2 будут выполнены различны м и MPI-задача м и. Кро м е того, такой тип параметризации м ожно распространить на контейнерные аргу м енты шаблонных функций. Это позволит передавать одной и той же шаблонной функции различные контейнеры объектов, содержащие различные типы объектов. Напри м ер, в листинге 9.3 показана обоб щ енная шаблоннал функция search ().

// Листинг 9.3. Использование контейнерных шаблонов в //   качестве аргументов шаблонных функций

template bool search(T Key, graph) {

//. . -

locate(Key) //. . .

}

// . . .

MPI_Comm_rank(MPI_COMM_WORLD, &TaskRank); // . . .

switch(TaskRank) {

case 1: {

graph bullion;

search search(«gold», bullion);

}

break; case 2: {

graph Coordinates; search((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.

Самолеты, вертолеты, автомобили и подводные лодки — все это потомки класса 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 bool travel(vehicle *Transport,

set 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 SearchSpace

travel(Car, SearchSpace,Street); //.. .

}

break;

case 2:

{

//.. .

helicopter *BlueThunder; set NationalAirSpace; travel(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 Object. Параметрический полиморфизм представляет собой механизм, благодаря которому один и тот же код используется для различных типов, передаваемых в качестве параметров. Различные типы полиморфизма, которые позволяют упростить МРТзадачи и сократить код, необходимый для реализации MPI-программы, перечислены в табл. 9.2.

Таблица 9.2. Различные типы полиморфизма, которые можно использовать  для упрощения МРI-задач

 

Введение MPMD-модели c помощью функций -объектов

Функции-объекты используются в стандартных алгоритмах для реализации горизонтального полиморфизма. Полиморфизм, реализованный с помощью передачи параметра vehicle *Transport в листинге 9.5, является вертикальным, поскольку для функционирования необходимо, чтобы классы были связаны наследованием. При горизонтальном полиморфизме классы связаны не наследованием, а интерфейсом. Все функции-объекты определяют операторную функцию operator (). Функции-объекты позволяют разрабатывать MPI-задачи с использованием некоторой общей формы.

// Функция-объект class some_class{ //.. .

operator(); //

};

template 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_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.

 

Перегрузка операторов «<<» и «>>» для организации взаимодействия между 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 &X);

mpi_stream &operator<<(vector &X),

mpi_stream &operator<<(vector &X);

mpi_stream &operator<<(vector &X);

mpi_stream &operator>>(int &X);

mpi_stream &operator>>(float &X);

mpi_stream &operator>>(string &X);

mpi_stream &operator>>(vector &X);

mpi_stream &operator>>(vector &X);

mpi_stream &operator>>(vector &X);

mpi_stream &operator>>(vector &X);

//. . .

};

Для того чтобы сократить описание, мы объединили классы impi _stream и ompi _stream в единый класс mpi _stream. И точно так же, как классы istream и ostream перегружают операторы "<<" и ">>", мы обеспечим их перегрузку в классе mpi_stream. В листинге 9.7 показано, как можно определить эти перегруженные операторы:

// Листинг 9.7. Определение операторов   и **»*

//. . .

mpi_stream &operator<<(string X) {

MPI_Send(const_cast(X.data()),X.size(),

MPI__CHAR, Rank, Tag, Comm) ; return(*this);

}

// Упрощенное управление буфером, mpi_stream &operator<<(vector &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 Z;

mpi_s tream S tream (Rank, Tag, MPI_WORLD_COMM) ;

Stream « X << Z; Stream << Y;

//...

Stream >> Z;

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

 

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

• классов, объектов, шаблонов, процессов и потоков;

• организации объектов, работающих «в одной команде».

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

 

Классы и объекты

 

Класс — это м о д ель некоторой конструкции, характеризую щ ейся опре д еленными атрибута м и и пове д ение м. Это — описание м ножества понятий или объектов, которые обладают об щ и м и атрибута м и. Класс — это базовый ко м понент любо й объектно-ориентированно й систе м ы. Классы м ожно и спользовать д ля пре д ставления реальных, концептуальных, аппаратных и про г ра мм ных конструкци й. Для пре д ставления классов, объектов и взаи м оотношений, которые су щ ествуют между ни м и в параллельной и/или распределенной систе м е, используется диаграмма класса (class diagram). Диа г ра м ма класса позволяет отобразить атрибуты и услу г и, предоставляе м ые классом, а также о г раничения, нала г ае м ые на способ связи этих классов/объектов.

Язык UML содержит средства для графического представления класса. Для простейшего изображения класса достаточно начертить прямоугольник и написать на нем имя класса. При использовании только одного имени говорят, что это простое гшя. С помощью диаграммы класса можно также отобразить атрибуты и услуги. предоставляемые пользователю этого класса (или операции, выполняемые этим классом). Чтобы включить в диаграмму атрибуты и операции, прямоугольник отображается с тремя горизонтальными отделениями. В верхнем отделении записывается простое имя класса, в среднем — атрибуты, а в нижнем — операции. Разделы атрибутов и операций можно пометить словами «атрибуты» и «операции» соответственно. Имя класса должно быть указано в любом случае, а раздел атрибутов или операций — по необходимости. Это значит, что если нужно указать один из разделов (атрибутов или операций), то другой отображается пустым. Различные способы представления класса показаны на рис. 10.1.

#img_52.png Рис. 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 * От нуля до бесконечности

* Бесконечное количество экземпляров

Безусловно, бесконечное количество экземпляров будет ограничено объемом внутренней или внешней памяти.

#img_53.png Рис. 10.2. Обозначение нескольких экземпляров класса с помощью графических средств и значения множественности

 

Отображение информации об атрибутах и операциях класса

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

StudentNumber : string;

Term : string

StudentSchedule : map >

ScheduleIterator : map >::iterator

Для oбъeктa mySchedule эти атрибуты могут принимать такие значения.

StudentNumber : string = «102933»

Term:string = «Spring»

Методы могут быть отображены с параметрами и с указанием типов возвращаемых ими значений.

studentSchedule(&X : map >) : 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 > {changeable}

Операции:

scheduleDayOfWeek(&X : vector, Day : string) :void {guarded}

studentNumber() : string {isQuery, concurrent}

Атрибут StudentNumber представляет собой константу типа string. После присвоения значение константы изменить нельзя. Если объект student_schedule используется для того же студента, но для различных периодов времени, то атрибуты Term и StudentSchedule должны быть модифицируемыми. Метод scheduleDayOfWeek () принимает вектор курсов (vector) для конкретного дня недели, хранимого в строке 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, б).

#img_54.png Рис. 10.3. Два способа организации атрибутов и операций в диаграмме класса

 

Шаблонные классы

Шаблонный класс представляет собой механизм, который позволяет в качестве параметра в определении класса использовать тип. Шаблон определяет действия, которые выполняются над переданным ему типом. В С++ параметризованный класс создается с помощью ключевого слова template.

template classname { . . . } ;

Параметр Туре представляет любой тип, передаваемый шаблону. Это может быть встроенный С++-тип или определенный пользователем класс. При объявлении параметра Туре шаблон связывается с эле м енто м, переданным ему в качестве параметризованного типа. Например, класс student_schedule включает контейнер map, который содержит векторы объектов типа course для каждого дня недели. Как класс map, так и класс vector являются шаблонными, map > StudentSchedule;

Контейнер map использует для ключа тип string, а для значения — тип vector. Контейнер vector содержит объекты определенно г о пользователе м типа course. Контейнер map может отобразить соответствие между значениями двух любых типов данных, а контейнер vector содержать значения любого типа данных.

map > Соответствие м ежду число м и векторо м строк

map >  Соответствие м ежлучисло м истрокой

vector  Вектор объектов класса student_schedule

vector

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

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

#img_55.png Рис. 10.4. Способы представления связанного и несвязанного шаблонного класса