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

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

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

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

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

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

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

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

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

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

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

Сходства

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

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

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

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

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

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

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

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

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

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

Различия

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

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

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

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

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

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

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

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

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

• Для переключения контекста требуется меньше системных ресурсов.

• Достигается более высокая производительность приложения.

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

• Программа имеет более простую структуру.

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

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

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

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

Простота доступности потоков к памяти процесса имеет свои недостатки.

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

• Потоки необходимо синхронизировать при параллельном доступе (для чтения или записи) к памяти.

• Один поток может ликвидировать целый процесс или программу.

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

Рис. 4.2. Взаимодействие между потоками одного процесса и взаимодействие между несколькими процессами

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

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

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

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

Как показано на рис. 4.3, процесс содержит два потока А и В, и их стеки располо жены в стековом разделе процесса. Потоки выполняют различные функции: поток А вы п олняет функцию func1(), а поток В - функцию func2().

Рис. 4.3. Схема процесса, содержащего два потока (SP — указатель стека, PC — счетчик команд)

Таблица 4.2. Преимущества и недостатки потоков

Преимущества потоков

Для переключения контекста требуется меньше системных ресурсов

Потоки способны повысить производительность приложения

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

Благодаря потокам структуру программы можно упростить

Недостатки потоков

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

Потоки могут разрушить адресное пространство своего процесса

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

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

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

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

• область видимости;

• размер стека;

• адрес стека;

• приоритет;

• состояние;

• стратегия планирования и параметры.

Объект атрибутов потока может быть связан с одним или несколькими потоками. При использовании этого объекта поведение потока или группы потоков определяется профилем. Все потоки, которые используют объект атрибутов, приобретают все свойства, определенные этим объектом. На рис. 4.3 показаны атрибуты, связанные с каждым потоком. Как видите, оба потока (А и В) разделяют объект атрибутов, но они поддерживают свои отдельные идентификационные номера и наборы регистров. После того как объект атрибутов создан и инициализирован, его можно использовать в любых обращениях к функциям создания потоков. Следовательно, можно создать группу потоков, которые будут иметь «малый стек и низкий приоритет» или «большой стек, высокий приоритет и состояние открепления». Открепленный (detached) поток — это поток, который не синхронизирован с другими потоками в процессе. Иначе говоря, не существует потоков, которые бы ожидали до тех пор, пока завершит выполнение открепленный поток. Следовательно, если уж такой поток существует, то его ресурсы (а именно id потока) немедленно принимаются на повторное использование. [8] Для установки и считывания значений этих атрибутов предусмотрены специальные методы. После создания потока его атрибуты нельзя изменить до тех пор, пока он существует.

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

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

Атрибут param— это структура, которую можно использовать для установки приоритета нового потока

Атрибут schedpolicy определяет стратегию планирования создаваемого потока

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

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

Атрибут stackaddr определяет базовый адрес стека, выделяемого для создаваемого потока

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

Когда подходит время для выполнения процесса, процессор занимает один из его оков. Если процесс имеет только один поток, то именно он (т.е. основной поток) назначается процессору. Если процесс содержит несколько потоков и в системе есть достаточно ^{е количе} ство процессоров, то процессорам назначаются все потоки. Потоки соперничают-за процессор либо со всеми потоками из активного процесса системы, либо только

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

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

Рис. 4.4. Состояния потоков и переходы между ними

При получении этого сигнала поток переходит из состояния останова в состояние готовности. Переход потока из одного состояния в другое является своего рода сигналом о наступлении некоторого события. Переход конкретного потока из состояния готовности _{в со} стояние выполнения происходит потому, что система выбрала именно его для выполнения, т.е. поток отправляется (dispatched) на процессор. Поток снимается, или выгружается (preempted), с процессора, если он делает запрос на ввод-вывод данных (или какой-либо иной запрос к ядру), или если существуют какие-то причины внешнего характера.

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

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

ПРИМЕЧАНИЕ: потоки при моделировании их реального поведения в приложении Должны иметь системную область конкуренции.

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

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

Рис. 4.5. Планирование потоков (с процессной и системной областями конкуренции) в мультипроцессорной среде

Как упоминалось в главе 3, очереди готовности организованы в виде отсортированных списков, в которых каждый элемент представляет собой уровень приоритета. Под уровнем приоритета понимается очередь потоков с одинаковым значением приоритета. Все потоки одного уровня приоритета назначаются процессору с использованием стратегии планирования: FIFO (сокр. от First In First OuU т.е. первым прибыл, первым обслужен), RR (сокр. от round-robin, т.е. циклическая) или какой-либо другой. При использовании стратегии планирования FIFO поток, квант процессорного времени которого истек, помещается в головную часть очереди соответствующего приоритетного уровня, а процесс назначается следующему потоку из очереди. Следовательно, поток будет выполняться до тех пор, пока он не завершит выполнение, не перейдет в состояние ожидания («заснет») или не получит сигнал остановиться. Когда «спящий» поток «просыпается», он помещается в конец очереди соответствующего приоритетного уровня. Стратегия планирования RR аналогична FIFO стратегии, за исключением того, что по истечении кванта процессорного времени поток помещается не в начало, а в конец «своей» очереди. Циклическая стратегия планирования (RR) считает все потоки обладающими одинаковыми приоритетами и каждому потоку предоставляет процессор только в течение некоторого кванта времени. Поэтому выполнение задач получается попеременным. Например, программа, которая выполняет поиск файлов по заданным ключевым словам, разбивается на два потока. Один поток (1) находит все файлы с заданным расширением и помещает их пути в контейнер. Второй поток (2) выбирает имена файлов из контейнера, просматривает каждый файл на предмет наличия в нем заданных ключевых слов, а затем записывает имена файлов, которые содержат такие слова. Если к этим потокам применить циклическую стратегию планирования с единственным процессором, то поток 1 использовал бы свой квант времени для поиска файлов и вставки их путей в контейнер. Поток 2 использовал бы свой квант времени для выделения имен файлов и поиска заданных ключевых слов. В идеальном мире потоки 1 и 2 должны выполняться попеременно. Но в действительности все может быть иначе. Например, поток 2 может выполниться до потока 1, когда в контейнере еще нет ни одного файла, или поток 1 может так долго искать файл, что до истечения кванта времени не успеет записать его путь в контейнер. Такая ситуация требует синхронизации, краткое рассмотрение которой приводится ниже в этой главе и в главе 5. Стратегия планирования FIFO позволяет каждому потоку выполняться до завершения. Если рассмотреть тот же пример с использованием FIFO-стратегии, то поток 1 будет иметь достаточно времени, чтобы отыскать все нужные файлы и вставить их пути в контейнер. Поток 2 затем выделит имена файлов и выполнит поиск заданных ключевых слов. В идеальном мире завершение выполнения потока 2 будет означать завершение программы в целом. Но в реальном мире поток 2 может быть назначен процессору до потока 1, когда контейнер еще не будет содержать файлов для поиска в них ключевых слов. После «холостого» выполнения потока 2 процессору будет назначен поток 1, который может успешно отыскать нужные файлы и поместить в контейнер их пути. Однако поиск ключевых слов выполнять уже будет некому. Поэтому программа в целом потерпит фиаско. При использовании FIFO-стратегии не предусматривается перемешивания задач. Поток, назначенный процессору, занимает его До полного выполнения своей задачи. Такую стратегию планирования можно использовать для приложений, в которых потоки необходимо выполнить как можно скорее.

°Д Другими» стратегиями планирования подразумеваются уже рассмотренные, но с небольшими вариациями. Например, FIFO-стратегия может быть изменена таким

разом, чтобы позволить разблокировать потоки, выбранные случайно.

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

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

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

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

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

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

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

• конвейер;

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

Каждая модель характеризуется собственной декомпозицией работ (Work Breakdown Structure — WBS), которая определяет, кто отвечает за создание потоков и при каких условиях они создаются. Например, существует централизованный подход, при котором один поток создает другие потоки и каждому из них делегирует некоторую работу. Существует также конвейерный (assembly-line) подход, при котором на различных этапах потоки выполняют различную работу. Созданные потоки могут выполнять одну и ту же задачу на различных наборах данных, различные задачи на одном и том же наборе данных или различные задачи на различных наборах данных. Потоки подразделяются на категории по выполнению задач только определенного типа. Например, можно создать группы потоков, которые будут выполнять только вычисления, только ввод или только вывод данных.

Возможны задачи, для успешного решения которых следует комбинировать перечисленные выше модели. В главе 3 мы рассматривали процесс визуализации. За-Дачи 1, 2 и 3 выполнялись последовательно, а задачи 4, 5 и 6 могли выполняться параллельно. Все задачи можно выполнить различными потоками. Если необходимо визуализировать несколько изображений, потоки 1, 2 и 3 могут сформировать конвейер. По завершении потока 1 изображение передается потоку 2, в то время ^к ак поток 1 может выполнять свою работу над следующим изображением. После буферизации изображений потоки 4, 5 и 6 могут реализовать параллельную обработку. Модель функционирования потоков представляет собой часть ^{структурирования па} раллелизма в приложении, в котором каждый поток может выполняться на отдельном процессоре. Модели функционирования потоков (и их краткое описание) приведены в табл. 4.4.

Таблица 4.4. Модели функционирования потоков

Модель

Описание

Модель делегирования

Модель с равно-правными узлами

Конвейер

Модель

«изготовитель-потребитель "

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

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

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

Поток-«изготовитель» готовит данные , потребляемые потоком- «потребителем». Данные сохраняются в блоке памяти, разделяемом потоками — «изготовителем» и «потребителем»

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

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

программировать на обработку запросов только определенного типа. Если тип _{запроса в} очереди не совпадает с типом запросов, на обработку которых ориентирован данный поток, то он может снова приостановиться. Главная цель управляю-потока — создать все потоки, поместить задания в очередь и «разбудить» рабочие потоки, когда эти задания станут доступными. Рабочие потоки справляются о наличии запроса в очереди, выполняют назначенную задачу и приостанавливаются сами, если для них больше нет работы. Все рабочие и управляющий потоки выполняются параллельно. Описанные два подхода к построению модели делегирования представлены для сравнения на рис. 4.6.

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

Рис. 4.7. Модель равноправных потоков (или модель с равноправными узлами)

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

Рис. 4.8. Модель конвейера

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

В каждой из описанных выше моделей потоки вновь и вновь выполняют одну и ту задачу на различных наборах данных или им назначаются различные задачи для выполнения на различных наборах данных. Эти потоковые модели используют схемы (Single-Program, Multiple-Data — одна программа, несколько потоков данных) и MPMD (Multiple-Programs, Multiple-Data — множество программ, множество потоков данных). Эти схемы представляют собой модели параллелизма, которые делят программы на потоки инструкций и данных. Их можно использовать для описания типа работы, которую реализуют потоковые модели с использованием параллелизма. В контексте нашего изложения материала модель MPMD лучше представить как модель MTMD (Multiple-Threads, Multiple-Data— множество потоков выполнения, множество потоков данных). Эта модель описывает систему с различными потоками выполнения (thread), которые обрабатывают различные наборы данных, или потоки данных (stream). Аналогично модель SPMD нам лучше рассматривать как модель STMD (Single-Thread, Multiple-Data — один поток выполнения, несколько потоков данных). Эта модель описывает систему с одним потоком выполнения, который обрабатывает различные наборы, или потоки, данных. Это означает, что различные наборы данных обрабатываются несколькими идентичными потоками выполнения (вызывающими одну и ту же подпрограмму).

Рис. 4.9. Модель конвейера

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

Библиотека Pthread предоставляет API-интерфейс для создания и управления потоками в приложении. Библиотека Pthread основана на стандартизированном интерфейсе программирования, который был определен комитетом по выпуску стандартов IEEE в стандарте POSIX 1003.1с. Сторонние фирмы-изготовители придерживаются стандарта POSIX в реализациях, которые именуются библиотеками потоков Pthread или POSIX.

Рис. 4.10. Модели параллелизма STMD и MTMD

Библиотека Pthread содержит более 60 функций, которые можно разделить на следующие категории.

1. Функции управления потоками.

1.1. Конфигурирование потоков.

1.2. Отмена потоков.

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

1.4. Доступ к данным потоков.

1.5. Обработка сигналов.

1.6. Функции доступа к атрибутам потоков.

1.6.1. Конфигурирование атрибутов потоков.

1.6.2. Конфигурирование атрибутов, относящихся к стекам потоков.

1.6.3. Конфигурирование атрибутов, относящихся к стратегиям планирования потоков.

2. Функции управления мьютексами.

2.1. Конфигурирование мьютексов.

2.2. Управление приоритетами.

2.3. Функции доступа к атрибутам мьютексов.

2.3.1. Конфигурирование атрибутов мьютексов.«

2.3.2. Конфигурирование атрибутов, относящихся к протоколам мьютексов.

2.3.3. Конфигурирование атрибутов, относящихся к управлению приоритетами мьютексов.

3. Функции управления условными переменными.

3.1. Конфигурирование условных переменных.

3.2. Функции доступа к атрибутам условных переменных.

3.2.1. Конфигурирование атрибутов условных переменных.

3.2.2. Функции совместного использования условных переменных.

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

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

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

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

#include <iostream>

#include <pthread.h>

void *task1(void *X) //define task to be executed by ThreadA

{

//...

cout << «Thread A complete» << endl;

}

void *task2(void *X) //define task to be executed by ThreadB

{

//...

cout << «Thread B complete» << endl;

}

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

{

pthread_t ThreadA,ThreadB; // declare threads

pthread_create(&ThreadA,NULL,task1,NULL); // create threads

pthread_create(&ThreadB,NULL,task2,NULL);

// additional processing

pthread_join(ThreadA,NULL); // wait for threads

pthread_join(ThreadB,NULL);

return(0);

}

В листинге 4.1 делается акцент на определении набора инструкций для основного потока. Основным в данном случае является управляющий поток, который объявляет два рабочих потока ThreadA и ThreadB. С помощью функции pthread_create () эти два потока связываются с задачами, которые они должны выполнить (taskl и task2). Здесь (ради простоты примера) эти задачи всего лишь отп равляют сообщение в стандартный выходной поток, но понятно, что они могли бы быть запрограммированы на нечто более полезное. При вызове функции pthread_create () потоки немедленно приступают к выполнению назначенных им задач. Работа функции pthread_join() аналогична работе функции wait() для процессов. Основной поток ожидает до тех пор, пока не завершатся оба рабочих потока. Диаграмма последовательностей, соответствующая листингу 4.1, показана на рис. 4.11. Обратите внимание на то, что происходит с потоками выполнения при вызове функций pthread_create() и pthread_join ().

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

Рис. 4.11. Диаграмма последовательностей, соответствующая листингу 4.1

Все многопоточные программы, использующие библиотеку потоков POSIX, должны включать заголовок: < pthread.h >

Для компиляции многопоточного приложения в средах UNIX или Linux с помощью компиляторов командной строки g++ или gcc необходимо скомпоновать его с библиотекой Pthreads. Для задания библиотеки используйте опцию -l. Так, команда -lpthread обеспечит компоновку вашего приложения с библиотекой, которая согласуется с многопоточным интерфейсом, определенным стандартом POSIX 1003.1с. Библиотеку Pthread, libpthread.so , следует поместить в каталог, в котором хранится системная стандартная библиотека, обычно это /usr/lib. Если она будет находиться не в стандартном каталоге, то для того, чтобы обеспечить поиск компилятора в заданном каталоге до поиска в стандартных, используйте опцию -L. По команде g++ -о blackboard -L /src/local/lib blackboard.cpp -lpthread компилятор выполнит поиск библиотеки Pthread сначала в каталоге /src/local/lib, а затем в стандартных каталогах.

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

Библиотека Pthreads используется для создания, поддержки и управления потоками многопоточных программ и приложений. При создании многопоточной программы потоки могут создаваться на любом этапе выполнения процесса, поскольку это — динамические образования. Функция pthread_create() создает новый поток в адресном пространстве процесса. Параметр thread указывает на дескриптор, или идентификатор (id), создаваемого потока. Новый поток будет иметь атрибуты, заданные объектом attr. Созданный поток немедленно приступит к выполнению инструкций, заданных параметром start_routine с использованием аргументов, заданных параметром arg. При успешном создании потока функция возвращает его идентификатор (id), значение которого сохраняется в параметре thread.

Синопсис

#include <pthread.h>

int pthread_create(pthread_t *restrict thread,

const pthread_attr_t *restrict attr,

void *(*start_routine)(void*),

void *restrict arg) ;

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

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

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

pthread_create(&threadA,NULL, taskl,NULL) ;

pthread_create(&threadB,NULL, task2, NULL) ;

Это — два вызова функции pthread_create () из листинга 4 .1. Оба потока создаются с атрибутами, действующими по умолчанию.

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

// Программа 4.1

#include <iostream>

#include <pthread.h>

#include <stdlib.h>

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

pthread_t ThreadA,ThreadB;

int N;

if(argc != 2) {

cout << «error» << endl;

exit (1);

}

N = atoi(argv[l]);

pthread_create(&ThreadA,NULL, taskl,&N);

pthread_create(&ThreadB,NULL, task2, &N);

cout « «Ожидание присоединения потоков.» « endl;

pthread_join(ThreadA,NULL) ;

pthread_join(ThreadB,NULL);

return (0) ;

};

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

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

// Программа 4.2

void *task1(void *X)

{

int *Temp;

Temp = static_cast<int *>(X);

for(int Count = 1;Count < *Temp;Count++){

cout << «work from thread A: " << Count << " * 2 = "

<< Count * 2 << endl;

}

cout << «Thread A complete» << endl;

}

void *task2(void *X)

{

int *Temp;

Temp = static_cast<int *>(X);

for(int Count = 1;Count < *Temp;Count++){

cout << «work from thread B: " << Count << " + 2 = "

<< Count + 2 << endl;

}

cout << «Thread B complete» << endl;

}

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

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

Имя программы •program4-12.cc

* Описание Принимает целочисленное значение из командной строки и передает функциям: потоков. Каждая функция выполняет цикл, в котором переменная цикла увеличивается (в одной функции на два, а в другой в два раза), а затем результат отсылается в стандартный поток вывода данных. Код основного потока выполнения приведен в программе 4.1, а код функций — в программе 4.2.

Требуемая библиотека libpthread

Требуемые заголовки <pthread.h> <iostream> <stdlib.h>

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

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

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

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

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

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

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

Синопсис

#include <pthread.h>

pthread_t pthread_self(void)

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

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

pthread_t ThreadId;

ThreadId = pthread_self();

Поток вызывает функцию pthread_self(), а значение, возвращаемое ею (идентификатор потока), сохраняет в переменной ThreadId типа pthread_t.

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

Синопсис

#include <pthread.h>

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

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

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

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

Синопсис

#include <pthread.h>

int pthread_detach(pthread_t thread thread);

При успешном выполнении эта функция возвращает число 0 , в противном случае— код ошибки. Функция pthread_detach() не будет успешной, если заданный поток уже откреплен или поток, заданный параметром thread, не был обнаружен.

Вот пример открепления уже существующего присоединяемого потока:

pthread_create(&threadA,NULL,taskl,NULL);

pthread_detach(threadA);

При выполнении этих строк кода поток threadA станет открепленным. Чтобы создать открепленный поток (в противоположность динамическому откреплению потока) необходимо установить атрибут detachstate в объекте атрибутов потока и использовать этот объект при создании потока.

Объект атрибутов инкапсулирует атрибуты потока или группы потоков. Он используется для установки атрибутов потоков при их создании. Атрибутный объект потока имеет тип pthread_attr_t. Он представляет собой структуру, позволяющую хранить следующие атрибуты:

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

• местоположение стека потока;

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

• тип потока: открепленный или присоединяемый;

• область конкуренции потока.

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

Для инициализации и разрушения атрибутного объекта потока используются функции pthread_attr_init () и pthread_attr_destroy () соответственно.

Синопсис

#include <pthread.h>

int pthread_attr_init(pthread_attr_t *attr);

int pthread_attr_destroy(pthread attr__t *attr) ;

Функция pthread_attr_init () инициализирует атрибутный объект потока с помощью стандартных значений, действующих для всех этих атрибутов. Параметр attr представляет собой указатель на объект типа pthread_attr_t. После инициализации attr-объекта значения его атрибутов можно изменить с помощью функций, перечисленных в табл. 4.3. После соответствующей модификации атрибутов значение attr используется в качестве параметра при вызове функции создания потока pthread_create(). При успешном выполнении эта функция возвращает число 0, в противном случае — код ошибки. Функция pthread_attr_init() завершится неуспешно, если для создания объекта в системе недостаточно памяти.

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

После инициализации объекта потока его атрибуты можно модифицировать. Дл _я установки атрибута detachstate атрибутного объекта используется функция pthread__attr_setdetachstate(). Параметр detachstate описывает поток как открепленный или присоединяемый.

Синопсис

#include <pthread.h>

int pthread_attr_setdetachstate(

pthread_attr_t *attr,

int *detachstate

);

int pthread_attr_getdetachstate(

const pthread_attr_t *attr,

int *detachstate

);

Параметр detachstate может принимать одно из следующих значений:

PTHREAD_CREATE_DETACHED

PTHREAD_CREATE_JOINABLE

Значение PTHREAD_CREATE_DETACHED « превращает» все потоки, которые используют этот атрибутный объект, в открепленные, а значение PTHREAD_CREATE_JОINABLE — в присоединяемые. Значение PTHREAD_CREATE_JOINABLE атрибут detachstate принимает по умолчанию. При успешном выполнении функция pthread_attr_setdetachstate () возвращает число 0 , в противном случае — код ошибки. Эта функция выполнится неуспешно, если значение параметра detachstate окажется недействительным.

Функция pthread_attr_getdetachstate () возвращает значение атрибута detachstate атрибутного объекта потока. При успешном выполнении эта функция возвращает значение атрибута detachstate в параметре detachstate и число 0 обычным способом. При неудаче функция возвращает код ошибки. В листинге 4.2 показано, как открепляются потоки, созданные в программе4.1. В этом примере при создании одного из потоков используется объект атрибутов.

// Листинг 4.2. Использование атрибутного объекта для // создания открепленного потока

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

pthread_t ThreadA,ThreadB;

pthread_attr_t DetachedAttr;

int N;

if(argc != 2) {

cout « «Ошибка» << endl; exit (1);

}

N = atoi(argv[1]);

pthread_attr_init(&DetachedAttr);

pthread_attr_setdetachstate(&DetachedAttr,PTHREAD_CREATE_DETACHED);

pthread_create(&ThreadA,NULL, task1, &N);

pthread_create(&ThreadB,&DetachedAttr,task2 , &N);

cout << «Ожидание присоединения потока А.» << endl; pthread_join(ThreadA,NULL);

return (0) ;

}

В листинге 4.2 объявляется атрибутный объект DetachedAttr, для инициализации которого используется функция pthread_attr_init(). После инициализации этого объекта вызывается функция pthread_attr_detachstate(), которая изменяет свойство detachstate («присоединяемость»), установив значение PTHREAD_CREATE_DETACHED («открепленность»). При создании потока ThreadB с помощью функции pthread_create() в качестве ее второго аргумента используется модифицированный объект DetachedAttr. Для потока ThreadB вызов функции pthread_join() не используется, поскольку открепленные потоки присоединить невозможно.

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

Выполнение потока может быть прервано по разным причинам:

• в результате выхода из процесса с возвращаемым им статусом завершения (или без него);

• в результате собственного завершения и предоставления статуса завершения;

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

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

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

Синопсис

#include <pthread.h>

int pthread_exit(void *value_ptr);

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

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

Синопсис

#include <pthread.h>

int pthread_cancel(pthread_t thread);

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

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

Состояние готовности к аннулированию (cancelability state) описывает условия, при которых поток может (или не может) быть аннулирован. Тип аннулирования (cancelabilty type) потока определяет способность потока продолжать выполнение после получения запросов на аннулирование. Поток может отреагировать на аннулирующий запрос немедленно или отложить аннулирование до определенной (более поздней) точки в его выполнении. Состояние готовности к аннулированию и тип аннулирования устанавливаются динамически самим потоком.

Для определения состояния готовности к аннулированию и типа аннулирования вызывающего потока используются функции p thread_setcancelstate() pthread_setcanceltype(). Функция pthread_setcancelstate() устанавливает вызывающий поток в состояние, заданное параметром state, и возвращает предыдущее состояние в параметре oldstate.

Синопсис

#include <pthread.h>

int pthread_setcancelstate(int state, int *oldstate);

int pthread_setcanceltype(int type, int *oldtype);

Параметры state и oldstate могут принимать такие значения:

PTHREAD_CANCEL_DISABLE

PTHREAD_CANCEL_ENABLE

Значение PTHREAD_CANCEL_DISABLE определяет состояние, в котором поток будет игнорировать запрос на аннулирование, а значение PTHREAD_CANCEL_ENABLE - состояние, в котором поток «согласится» выполнить соответствующий запрос (это состояние по умолчанию устанавливается для каждого нового потока). При успешном выполнении функция возвращает число 0 , в противном случае — код ошибки. Функция pthread_setcancelstate() не может выполниться успешно, если переданное

значение параметра state окажется недействительным. Функция pthread_setcanceltype () устанавливает для вызывающего потока тип аннулирования, заданный параметром type, и возвращает предыдущее значение типа в параметре oldtype. Параметры type и oldtype могут принимать такие значения:

PTHREAD_CANCEL_DEFFERED

PTHREAD_ASYNCHRONOUS

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

Функции pthread_setcancelstate() и pthread_setcanceltype() используются вместе для установки отношения вызывающего потока к потенциальному запросу на аннулирование. Возможные комбинации значений состояния и типа аннулирования перечислены и описаны в табл. 4 .5.

Таблица 4.5. Комбинации значений состояния и типа аннулирования

Состояние   Тип   Описание

PTHREAD_CANCEL_ENABLE (PTHREAD_CANCEL_DEFERRED) Отсроченное аннулирование. Эти состояние и тип аннулирования потока устанавливаются по умолчанию. Аннулирование потока происходит, когда он достигает соответствующей точки в своем выполнении или когда программист определяет точку аннулирования с помощью функции pthread_testcancel()

PTHREAD_CANCEL_ENABLE (PTHREAD_CANCEL_ASYNCHRONOUS)

Асинхронное аннулирование. Аннулирование потока происходит немедленно

PTHREAD_CANCEL_DISABLE (любое)

Аннулирование запрещено. Оно вообще не выполняется

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

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

Синопсис

#include <pthread.h>

void pthread_testcancel(void)

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

#include <iostream>

#include <pthread.h>

void *task1(void *X)

{

int OldState;

// disable cancelability

pthread_setcancelstate(PTHREAD_CANCEL_DISABLE,&OldState);

for(int Count = 1;Count < 100;Count++)

{

cout << «thread A is working: " << Count << endl;

}

}

void *task2(void *X)

{

int OldState,OldType;

// enable cancelability, asynchronous

pthread_setcancelstate(PTHREAD_CANCEL_ENABLE,&OldState);

pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS,&OldType);

for(int Count = 1;Count < 100;Count++)

{

cout << «thread B is working: " << Count << endl;

}

}

void *task3(void *X)

{

int OldState,OldType;

// enable cancelability, deferred

pthread_setcancelstate(PTHREAD_CANCEL_ENABLE,&OldState);

pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED,&OldType);

for(int Count = 1;Count < 1000;Count++)

{

cout << «thread C is working: " << Count << endl;

if((Count%100) == 0){

pthread_testcancel();

}

}

}

В программе 4.3 каждая задача устанавливает свое условие аннулирования. В задаче task1 аннулирование потока запрещено, поскольку вся она состоит из критического кода, который должен быть выполнен до конца. В задаче task2 аннулирование потока разрешено. Обращение к функции pthread_setcancelstate () является необязательным, поскольку все новые потоки имеют статус разрешения аннулирования. Тип аннулирования здесь устанавливается равным значению PTHREAD_CANCEL_ASYNCHRONOUS Это означает, что после поступления запроса на аннулирование поток немедленно запустит соответствующую процедуру, независимо от того, на какой этап его выполнения придется этот запрос. А поскольку этот поток установил для себя именно такой тип аннулирования, значит, он не выполняет никакого «жизненно важного» кода. Например, вызовы системных функций должны попадать под категорию опасных для аннулирования, но в задаче task2 таких нет. Там выполняется лишь цикл, который будет работать до тех пор, пока не поступит запрос на аннулирование. В задаче task3 аннулирование потока также разрешено, а тип аннулирования устанавливается равным значению PTHREAD_CANCEL_DEFFERED. Эти состояние и тип аннулирования действуют по умолчанию для новых потоков, следовательно, обращения к функциям pthread_setcancelstate() и pthread_setcanceltype() здесь необязательны. Критический код этого потока здесь может спокойно выполняться после установки состояния и типа аннулирования, поскольку процедура завершения не стартует до вызова функции pthread_testcancel (). Если не будут обнаружены ждущие запросы, поток продолжит свое выполнение до тех пор, пока не встретит очередные обращения к функции pthread_testcancel() (если таковые предусмотрены). В задаче task3 функция pthread_cancel () вызывается только после того, как переменная Count без остатка разделится на число 100 . Код, расположенный между точками аннулирования потока, не должен быть критическим, поскольку он может не выполниться.

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

// Программа 4.4

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

pthread_t Threads[3]; void *Status;

pthread_create(&(Threads[0]),NULL,taskl, NULL); pthread_create(&(Threads[l]), NULL,task2,NULL); pthread_create(&(Threads[2]),NULL,task3,NULL);

pthread_cancel(Threads[0]); pthread_cancel(Threads[l]); pthread_cancel(Threads[2]);

for(int Count = 0;Count < 3;Count++) {

pthread_join(Threads[Count],&Status); if(Status == PTHREAD_CANCELED){

cout << «Поток» << Count << " аннулирован.» << endl;

}

else{

cout « «Поток» << Count << " продолжает выполнение.» << endl;

}

}

return (0) ;

}

Управляющий поток в программе 4.4 сначала создает три рабочих потока, затем делает запрос на аннулирование каждого из них. Управляющий поток для каждого рабочего потока вызывает функцию pthread_join(). Эта функция завершается успешно даже тогда, когда она пытается присоединить поток, который уже завершен, функция присоединения в этом случае просто считывает статус завершения завершенного потока. И такое поведение весьма кстати, поскольку поток, который сделал запрос на аннулирование, и поток, вызвавший функцию pthread_join (), могут оказаться совсем разными потоками. Мониторинг функционирования всех рабочих потоков может оказаться единственной задачей того потока, который «по совместительству» и аннулирует потоки. Опрашивать же статус завершения потоков с помощью функции pthread_join() может совершенно другой поток. Этот тип информации используется для получения статистической оценки того, какой из потоков наиболее эффективен. В рассматриваемой нами программе все это делает один управляющий поток: в цикле он и присоединяет рабочие потоки, и проверяет их статус завершения. Поток Threads[0] не аннулирован, поскольку он имеет запрет на аннулирование, в то время как два остальных потока были аннулированы. Статус завершения аннулируемого потока может иметь, например, значение PTHREAD_CANCELED. Профили программ 4.3 и 4.4 представлены в разделе «Профиль программы 4.2».

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

Имя программы program4-34. cc ;

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

Требуемая библиотека libpthread

Тр ебуемые заголовки <pthread.h> <iostream>

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

с++ -о program4-34 program4-34.сс -lpthread

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

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

В функциях, определенных пользователем, используются точки аннулирования отмеченные обращением к функции pthread_testcancel(). Библиотека Pthread определяет в качестве точек аннулирования выполнение других функций. Эти функции блокируют вызывающий поток, а заблокированному потоку аннулирование не грозит. Вот эти функции библиотеки Pthread:

pthread_testcancel()

pthread_cond_wait()

pthread_timedwait()

pthread_join()

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

Таблица 4.6. Системные POSIX-функции, претендующие на роль точек аннулирования

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

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

Синопсис

#include <pthread.h>

void pthread_cleanup_push(void (*routine)(void *),void *arg);

void pthread cleanup pop(int execute);

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

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

Необходимо позаботиться о том, чтобы для каждой функции занесения в стек (push) существовала функция извлечения из стека (pop) в пределах одной и той же лексической области видимости. Например, для функции funcA () обязательно выполнение cleanup -обработчика при ее нормальном завершении или аннулировании:

void *funcA(void *X)

{

int *Tid;

Tid = new int;

// do some work

//...

pthread_cleanup_push(cleanup_funcA,Tid);

// do some more work

//...

pthread_cleanup_pop(0);

}

Здесь функция funcA( ) помещает указатель на обработчик cleanup_funcA( ) в стек завершающих процедур путем вызова функции pthread_cleanup_push (). Каждому обращению к этой функции должно соответствовать обращение к функции pthread_cleanup_pop(). Если функции извлечения указателя из стека (pop- функции) передается значение 0, то извлечение из стека состоится, но без выполнения обработчика. Обработчик будет выполнен лишь при аннулировании потока, выполняющего функцию funcA().

Для функции funcB () также требуется cleanup -обработчик:

void *funcB(void *X)

{

int *Tid;

Tid = new int;

// do some work

//...

pthread_cleanup_push(cleanup_funcB,Tid);

// do some more work

//...

pthread_cleanup_pop(1);

}

Здесь функция funcB () помещает указатель на обработчик cleanup_funcB () в стек завершающих процедур. Отличие этого примера от предыдущего состоит в том, что функции pthread_cleanup_pop () передается параметр со значением 1, т.е. после извлечения из стека указателя на обработчик этот обработчик будет тут же выполнен. Необходимо отметить, что выполнение обработчика в данном случае состоится «при любой погоде», т.е. и при аннулировании потока, который обеспечивает выполнение функции funcB( ), и при обычном его завершении. Обработчики- «уборщики», cleanup_funcA() и cleanup_funcB (), — это обычные функции, которые можно использовать для закрытия файлов, освобождения ресурсов, разблокирования мьютексов и пр.

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

Предположим, что поток А (см. рис. 4.12) выполняет функцию task1 () , которая создает некоторые локальные переменные, выполняет заданную обработку, а затем вызывает функцию taskX (). При этом для функции task1 () создается стековый фрейм, который помещается в стек потока. Функция taskX () выполняет «свои» действия, создает локальные переменные, а затем вызывает функцию taskC (). Нетрудно догадаться, что стековый фрейм, созданный для функции taskX () , также помещается в стек. Функция taskC () вызывает функцию taskY() и т.д. Каждый стек должен иметь достаточно большой размер, чтобы поместить всю информацию, необходимую для выполнения всех функций потока, а также цепочки других подпрограмм, которые будут вызваны потоковыми функциями. Размером и местоположением стека потока управляет операционная система, но для установки и считывания этой информации предусмотрены методы, которые определены в объекте атрибутов потока.

Рис. 4.12. Стековые фреймы, сгенерированные потоками

Функция pthread_attr_getstacksize( ) возвращает минимальный размер стека, устанавливаемый по умолчанию. Параметр attr определяет объект атрибутов потока, из которого считывается стандартный размер стека. При успешном выполнении функция возвращает значение 0, а стандартный размер стека, выраженный в байтах, coxpaняется в параметре stacksize. В случае неудачи функция возвращает код ошибки.

Функция pthread_attr_setstacksize() устанавливает минимальный размер стека. Параметр attr определяет объект атрибутов потока, для которого устанавливается размер стека. Параметр stacksize содержит минимальный размер стека, выраженный в байтах. При успешном выполнении функция возвращает значение 0 , в противном случае - код ошибки. Функция завершается неудачно, если значение параметра stacksize оказывается меньше значения PTHREAD_MIN_STACK или превышает системный минимум. Вероятно, значение PTHREAD_STACK_MIN будет меньше минимального размера стека, возвращаемого функцией p thread_attr_getstacksize(). Прежде чем увеличивать минимальный размер стека потока, следует поинтересоваться значением, возвращаемым функцией p thread_attr_getstacksize() р азмер ст ека фиксируется, чтобы его расширение во время выполнения программы ограничивалось рамками фиксированного пространства стека, установленного во время компиляции.

Синопсис

#include <pthread.h>

void pthread_attr_getstacksize(

const pthread_attr_t *restrict attr, void **restrict stacksize);

void pthread_attr_setstacksize(pthread_attr_t *attr, void *stacksize);

Местоположение стека потока можно установить и прочитать с помощью функций pthread_attr_setstackaddr() и pthread_attr_getstackaddr(). Функция pthread_attr_setstackaddr() для потока, создаваемого с помощью атрибутного объекта, заданного параметром attr, устанавливает базовый адрес стека равным адресу, заданному параметром stackaddr. Этот адрес stackaddr должен находиться в пределах виртуального адресного пространства процесса. Размер стека должен быть не меньше минимального размера стека, задаваемого значением PTHREAD_STACK_MIN. При успешном выполнении функция возвращает значение 0 , в противном случае — код ошибки.

Функция pthread_attr_getstackaddr () считывает базовый адрес стека для потока, создаваемого с помощью атрибутного объекта потока, заданного параметром attr. Считанный адрес сохраняется в параметре stackaddr. При успешном выполнении функция возвращает значение 0 , в противном случае — код ошибки.

Синопсис

#include <pthread.h>

void pthread_attr_setstackaddr(pthread_attr_t *attr,

void *stackaddr);

void pthread_attr_getstackaddr(const pthread_attr_t *restrict attr, void **restrict stackaddr);

Атрибуты стека (размер и местоположение) можно установить с помощью одной функции. Функция pthread_attr_setstack() устанавливает как размер, так и адрес стека для потока, создаваемого с помощью атрибутного объекта, заданного параметром attr. Базовый адрес стека устанавливается равным адресу, заданному параметром stackaddr, а размер стека — равным значению параметра stacksize. Функция pthread_attr_getstack() считывает размер и адрес стека для потока, создаваемого с помощью атрибутного объекта, заданного параметром attr. При успешном выполнении функция возвращает значение 0 , в противном случае — код ошибки. Если считывание атрибутов стека прошло успешно, адрес будет записан в параметр stackaddr, а размер— в параметр stacksize. Функция pthread_setstack() выполнится неудачно, если значение параметра stacksize окажется меньше значения PTHREAD_STACK_MIN или превысит некоторый предел, определяемый реализацией.

Синопсис

#include <pthread.h>

void pthread_attr_setstack(pthread_attr_t *attr, void *stackaddr,

size_t stacksize);

void pthread_attr_getstack(const pthread_attr_t *restrict attr,

void **restrict stackaddr, size_t stacksize);

В листинге 4.3 показан пример установки размера стека для потока, создаваемого с помощью атрибутного объекта.

// Листинг 4.3. Изменение размера стека для потока

//  с использованием смещения

pthread_attr_getstacksize(&SchedAttr, &DefaultSize) ;

if(DefaultSize < Min_Stack_Req){

SizeOffset = Min_Stack_Req - DefaultSize;

NewSize = DefaultSize + SizeOffset;

pthread_attr_setstacksize(&Attrl, (size_t)NewSize);

}

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

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

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

pthread_attr_setinheritsched()

pthread_attr_setschedpolicy()

pthread_attr_setschedparam()

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

pthread_attr_getinheritsched()

pthread_attr_getschedpolicy()

pthread_attr_getschedparam()

Синопсис

#include <pthread.h>

#include <sched.h>

void pthread_attr_setinheritsched(pthread_attr_t *attr, int inheritsched);

void pthread_attr_setschedpolicy(pthread_attr_t *attr, int policy);

void pthread_attr_setschedparam(pthread_attr_t *restrict attr,

const struct sched_param *restrict param);

Функции pthread_attr_setinheritsched(), pthread_attr_setschedpolicy () и pthread_attr_setschedparam() используются для установки стратегии планирования и приоритета потока. Функция pthread_attr_setinheritsched() позволяет определить, как будут устанавливаться атрибуты планирования потока: путем наследования от потока-создателя или в соответствии с содержимым объекта атрибутов. Параметр inheritsched может принимать одно из следующих значений.

PTHREAD_INHERIT_SCHED Атрибуты планирования потока должны быть унаследованы от потока-создателя, при этом любые атрибуты планирования, определяемые параметром attr, будут игнорироваться.

PTHREAD_EXPLICIT_SCHED Атрибуты планирования потока должны быть установлены в соответствии с атрибутами планирования, хранимыми в объекте, заданном параметром attr.

Если параметр inheritsched получает значение PTHREAD_EXPLICIT_SCHED, то функция pthread_attr_setschedpolicy() используется для установки стратегии планирования, а функция pthread_attr_setschedparam() — установки приоритета.

Функция pthread_attr_setschedpolicy() устанавливает член объекта атрибутов потока (заданного параметром attr), «отвечающий» за стратегию планирования потока. Параметр policy может принимать одно из следующих значений, определенных в заголовке <sched. h>.

SCHED_FIFO Стратегия планирования типа FIFO (первым прибыл, первым обслужен), при которой поток выполняется до конца.

SCHED_RR  Стратегия циклического планирования, при которой каждый поток

назначается процессору только в течение некоторого кванта времени- SCHED_OTHER Стратегия планирования другого типа (определяемая реализацией)-Для любого нового потока эта стратегия планирования принимается по умолчанию.

Функ ция pthread_attr_setschedparam() используется для установки членов атрибутного объекта (заданного параметром attr), связанных со стратегией планирования Параметр param представляет собой структуру, которая содержит эти члены. Структура sched_param включает по крайней мере такой член данных: struct sched_param {

int sched_priority;

//...

};

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

Чтобы получить минимальное и максимальное значения приоритета, используйте функции sched_get_priority_min () и sched_get_priority_max ().

Синопсис

#include <sched.h>

int sched_get_priority_max(int policy);

int sched_get_priority_min(int policy);

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

Как установить стратегию планирования и приоритет потока с помощью атрибутного объекта, показано в листинге 4.4.

// Листинг 4.4. Использование атрибутного объекта потока И   для установки стратегии планирования и

II   приоритета потока

#define Min_Stack_Req 3000000

pthread_t ThreadA;

pthread_attr_t SchedAttr;

size_t DefaultSize,SizeOffset,NewSize;

int MinPriority,MaxPriority,MidPriority;

sched_param SchedParam;

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

{

//...

// initialize attribute object

pthread_attr_init(&SchedAttr);

// retrieve min and max priority values for scheduling policy

MinPriority = sched_get_priority_max(SCHED_RR);

MaxPriority = sched_get_priority_min(SCHED_RR);

// calculate priority value

MidPriority = (MaxPriority + MinPriority)/2;

// assign priority value to sched_param structure

SchedParam.sched_priority = MidPriority;

// set attribute object with scheduling parameter

pthread_attr_setschedparam(&Attr1,&SchedParam);

// set scheduling attributes to be determined by attribute object

pthread_attr_setinheritsched(&Attr1,PTHREAD_EXPLICIT_SCHED);

// set scheduling policy

pthread_attr_setschedpolicy(&Attr1,SCHED_RR);

// create thread with scheduling attribute object

pthread_create(&ThreadA,&Attr1,task2,Value);

}

В листинге 4.4 стратегия планирования и приоритет потока ThreadA устанавливаются с использованием атрибутного объекта SchedAttr. Выполним следующие действия.

1. Инициализируем атрибутный объект.

2. Считаем минимальное и максимальное значения приоритета для стратегии планирования.

3. Вычислим значение приоритета.

4. Запишем значение приоритета в структуру sched_param.

5.  Установим атрибутный объект.

6. Обеспечим установку атрибутов планирования с помощью атрибутного объекта.

7. Установим стратегию планирования.

8. Создадим поток с помощью атрибутного объекта.

Последовательное выполнение этих действий позволяет установить стратегию планирования и приоритет потока до его создания. Для динамического изменения стратегии планирования и приоритета используйте функции pthread_setschedparam () и pthread_setschedprio().

Синопсис

#include <pthread.h>

int pthread_setschedparam(pthread_t thread,

int policy,

const struct sched_param *param);

int pthread_getschedparam(

pthread_t thread,

int *restrict policy,

struct sched_param *restrict param);

int pthread_setschedprio(pthread_t thread, int prio);  

Функция pthread_setschedparam() устанавливает как стратегию планирования, так и приоритет потока без использования атрибутного объекта. Параметр thread содержит идентификатор потока, параметр policy — новую стратегию планирования и параметр param — значения, связанные с приоритетом. Функция pthread_getschedparam() сохраняет значения стратегии планирования и приоритета в параметрах policy и param соответственно. При успешном выполнении обе функции возвращают число 0 , в противном случае — код ошибки. Условия, при которых эти функции могут завершиться неудачно, перечислены в табл. 4.7.

Таблица4.7. Условия потенциального неудачного завершения функций установки стратегии планирования и приоритета

Функции

Условия отказа

pthread_getschedparam

• Параметр thread не ссылается на существующий поток

pthread_setschedparam

• Некорректен параметр policy или один из членов структуры, на которую указывает параметр param

• Параметр policy или один из членов структуры, на которую указывает параметр param, содержит значение, которое не поддерживается в данной среде

• Вызывающий поток не имеет соответствующего разрешения на установку значений приоритета или стратегии планирования для заданного потока

• Параметр thread не ссылается на существующий поток

• Данная реализация не позволяет приложению заменить один из параметров планирования заданным значением

pthread_setschedprio

• Параметр prio не подходит к стратегии планирования заданного потока

• Параметр prio имеет значение, которое не поддерживается в данной среде

• Вызывающий поток не имеет соответствующего разрешения на установку приоритета для заданного потока

• Параметр thread не ссылается на существующий поток

• Данная реализация не позволяет приложению заменить значение приоритета заданным

Функция pthread_setschedprio() используется для установки значения приоритета выполняемого потока, идентификатор которого задан параметром thread В результате выполнения этой функции текущее значение приоритета будет заменено значением параметра prio. При успешном выполнении функция возвращает число 0 в противном случае — код ошибки. При неуспешном выполнении функции приоритет потока изменен не будет. Условия, при которых эта функция может завершиться неуспешно, также перечислены в табл. 4.7.

ПРИМЕЧАНИЕ: к изменению стратегии планирования или приоритета выполняемого потока необходимо отнестись очень осторожно. Это может непредсказуемым образом повлиять на общую эффективность приложения. Потоки с более высоким приоритетом будут вытеснять потоки с более низким, что приведет к зависанию либо к тому, что поток будет постоянно выгружаться с процессора и поэтому не сможет завершить выполнение.

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

Синопсис

#include <pthread.h>

int pthread_attr_setscope(pthread_attr_t *attr,

int contentionscope);

int pthread_attr_getscope(

const pthread_attr_t *restrict_attr,

int *restrict contentionscope) ;

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

PTHREAD_SCOPE_SYSTEM Область конкуренции системного уровня PTHREAD_SCOPE_PROCESS Область конкуренции уровня процесса

Функция pthread_attr_getscope() возвращает атрибут области конкуренции из объекта атрибутов потока, заданного параметром attr. При успешном выполнении значение области конкуренции сохраняется в параметре contentionscope. Обе функции при успешном выполнении возвращают число 0 , в противном случае — код ошибки-

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

Синопсис

#include <unistd.h>

#include <limits.h>

Параметр name - это запрашиваемая системная переменная. Функция возвращает значения, соответствующие стандарту POSIX IEEE Std. 1003.1-2001 для заданных системных переменных. Эти значения можно сравнить с константами, определенными вашей реализацией стандарта, чтобы узнать, насколько они согласуются между собой. Для ряда системных переменных существуют константы-аналоги, относящиеся к потокам, процессам и семафорам (см. табл. 4.8).

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

if(PTHREAD_STACK_MIN == (sysconf(_SC_THREAD_STACK_MIN))){

//...

}

Значение константы PTHREAD_STACK_MIN сравнивается со значением, возвращаемым функцией sysconf (), вызванной с параметром _SC_THREAD_STACK_MIN.

Таблица4 .8. Системные переменные и соответствующие им символьные константы

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

Если существуют процессы или потоки, которые получают доступ к разделяемым модифицируемым данным, структурам данных или переменным, то все эти данные находятся в критической области (или разделе) кода процессов или потоков. Критический раздел кода — это та его часть, в которой обеспечивается доступ потока или процесса к разделяемому блоку модифицируемой памяти и обработка соответствующих данных. Отнесение раздела кода к критическому можно использовать для управления состоянием «гонок». Например, создаваемые в программе два потока, поток А и поток В, используются для поиска нескольких ключевых слов во всех файлах системы. Поток А просматривает текстовые файлы в каждом каталоге и записывает нужные пути в списочную структуру данных TextFiles, а затем инкрементирует переменную FileCount. Поток В выделяет имена файлов из списка TextFiles, декрементирует переменную FileCount, после чего просматривает файл на предмет поиска в нем заданных ключевых слов. Файл, который их содержит, переписывается в другой файл, и инкрементируется еще одна переменная FoundCount. К переменной FoundCount поток А доступа не имеет. Потоки А и В могут выполняться одновременно на отдельных процессорах. Поток А выполняется до тех пор, пока не будут просмотрены все каталоги, в то время как поток В просматривает каждый файл, путь к которому выделен из переменной TextFiles. Упомянутый список поддерживается в отсортированном порядке, и в любой момент его содержимое можно отобразить на экране.

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

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

Для управления условиями «гонок» можно использовать такой механизм блокировки, как взаимо - исключающий семафор , или мьютекс (mutex— сокращение от «mutual exclusion», - взаимное исключение). Мьютекс используется для блокирования критического раздела: он блокируется до входа в критический раздел, а при выходе из него - деблокируется:

Блокирование мьютекса

// Вход в критический раздел.

// Доступ к разделяемой модифицируемой памяти.

// Выход из критического раздела.

Деблокирование мьютекса

Класс pthread_mutex_t позволяет смоделировать мьютексный объект. Прежде, чем объект типа pthread_mutex_t можно будет использовать, его необходимо инициализировать. Для инициализации мьютекса используется функция pthread_mutex_init(). Инициализированный мьютекс можно заблокировать деблокировать и разрушить с помощью функций pthread_mutex_lock(), pthread_mutex_unlock () и pthread_mutex_destroy () соответственно. В программе 4.5 содержится функция, которая выполняет поиск текстовых файлов, а в программе 4.6 — функция, которая просматривает каждый текстовый файл на предмет содержания в нем заданных ключевых слов. Каждая функция выполняется потоком. Основной поток реализован в программе 4.7. Эти программы реализуют модель «изготовитель-потребитель» для делегирования задач потокам. Программа4.5 содержит поток-«изготовитель», а программа 4.6 — поток-«потребитель». Критические разделы выделены в них полужирным шрифтом.

// Программа 4.5

1 int isDirectory(string FileName)

2 {

3 struct stat StatBuffer;

4

5 lstat(FileName.c_str(),&StatBuffer);

6 if((StatBuffer.st_mode & S_IFDIR) == -1)

7 {

8 cout << «could not get stats on file» << endl;

9 return(0);

10 }

11 else{

12 if(StatBuffer.st_mode & S_IFDIR){

13 return(1);

14 }

15 }

16 return(0);

17 }

18

19

20 int isRegular(string FileName)

21 {

22 struct stat StatBuffer;

23

24 lstat(FileName.c_str(),&StatBuffer);

25 if((StatBuffer.st_mode & S_IFDIR) == -1)

26 {

27 cout << «could not get stats on file» << endl;

28 return(0);

29 }

30 else{

31 if(StatBuffer.st_mode & S_IFREG){

32 return(1);

33 }

34 }

35 return(0);

36 }

37

38

39 void depthFirstTraversal(const char *CurrentDir)

40 {

41 DIR *DirP;

42 string Temp;

43 string FileName;

44 struct dirent *EntryP;

45 chdir(CurrentDir);

46 cout << «Searching Directory: " << CurrentDir << endl;

47 DirP = opendir(CurrentDir);

48

49 if(DirP == NULL){

50 cout << «could not open file» << endl;

51 return;

52 }

53 EntryP = readdir(DirP);

54 while(EntryP != NULL)

55 {

56 Temp.erase();

57 FileName.erase();

58 Temp = EntryP->d_name;

59 if((Temp != ".») && (Temp != "..»)){

60 FileName.assign(CurrentDir);

61 FileName.append(1,'/');

62 FileName.append(EntryP->d_name);

63 if(isDirectory(FileName)){

64 string NewDirectory;

65 NewDirectory = FileName;

66 depthFirstTraversal(NewDirectory.c_str());

67 }

68 else{

69 if(isRegular(FileName)){

70 int Flag;

71 Flag = FileName.find(".cpp»);

72 if(Flag > 0){

73 pthread_mutex_lock(&CountMutex);

74 FileCount++;

75 pthread_mutex_unlock(&CountMutex);

76 pthread_mutex_lock(&QueueMutex);

77 TextFiles.push(FileName);

78 pthread_mutex_unlock(&QueueMutex);

79 }

80 }

81 }

82

83 }

84 EntryP = readdir(DirP);

85 }

86 closedir(DirP);

87 }

88

89

90

91 void *task(void *X)

92 {

93 char *Directory;

94 Directory = static_cast<char *>(X);

95 depthFirstTraversal(Directory);

96 return(NULL);

97

98 }

Программа 4.6 содержит поток-«потребитель», который выполняет ных ключевых слов.

// Программа 4.6

1 void *keySearch(void *X)

2 {

3 string Temp, Filename;

4 less<string> Comp;

5

6 while(!Keyfile.eof() && Keyfile.good())

7 {

8 Keyfile >> Temp;

9 if(!Keyfile.eof()){

10 KeyWords.insert(Temp);

11 }

12 }

13 Keyfile.close();

14

15 while(TextFiles.empty())

16 { }

17

18 while(!TextFiles.empty())

19 {

20 pthread_mutex_lock(&QueueMutex);

21 Filename = TextFiles.front();

22 TextFiles.pop();

23 pthread_mutex_unlock(&QueueMutex);

24 Infile.open(Filename.c_str());

25 SearchWords.erase(SearchWords.begin(),SearchWords.end());

26

27 while(!Infile.eof() && Infile.good())

28 {

29 Infile >> Temp;

30 SearchWords.insert(Temp);

31 }

32

33 Infile.close();

34 if(includes(SearchWords.begin(),SearchWords.end(),

KeyWords.begin(),KeyWords.end(),Comp)){

35 Outfile << Filename << endl;

36 pthread_mutex_lock(&CountMutex);

37 FileCount--;

38 pthread_mutex_unlock(&CountMutex);

39 FoundCount++;

40 }

41 }

42 return(NULL);

43

44 }

Программа 4.7 содержит основной поток для потоков модели «изготовитель-потребитель», реализованных в программах 4.5 и 4.6.

// Программа 4.7

1 #include <sys/stat.h>

2 #include <fstream>

3 #include <queue>

4 #include <algorithm>

5 #include <pthread.h>

6 #include <iostream>

7 #include <set>

8

9 pthread_mutex_t QueueMutex = PTHREAD_MUTEX_INITIALIZER;

10 pthread_mutex_t CountMutex = PTHREAD_MUTEX_INITIALIZER;

11

12 int FileCount = 0;

13 int FoundCount = 0;

14

15 int keySearch(void);

16 queue<string> TextFiles;

17 set <string,less<string> >KeyWords;

18 set <string,less<string> >SearchWords;

19 ifstream Infile;

20 ofstream Outfile;

21 ifstream Keyfile;

22 string KeywordFile;

23 string OutFilename;

24 pthread_t Thread1;

25 pthread_t Thread2;

26

27 void depthFirstTraversal(const char *CurrentDir);

28 int isDirectory(string FileName);

29 int isRegular(string FileName);

30

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

32 {

33 if(argc != 4){

34 cerr << «need more info» << endl;

35 exit (1);

36 }

37

38 Outfile.open(argv[3],ios::app||ios::ate);

39 Keyfile.open(argv[2]);

40 pthread_create(&Thread1,NULL,task,argv[1]);

41 pthread_create(&Thread2,NULL,keySearch,argv[1]);

42 pthread_join(Thread1,NULL);

43 pthread_join(Thread2,NULL);

44 pthread_mutex_destroy(&CountMutex);

45 pthread_mutex_destroy(&QueueMutex);

46

47 cout << argv[1] << " contains " << FoundCount

<< " files that contains all keywords.» << endl;

48 return(0);

49 }

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

• EREW (монопольное чтение и монопольная запись)

• CREW (параллельное чтение и монопольная запись)

• ERCW (монопольное чтение и параллельная запись)

• CRCW (параллельное чтение и параллельная запись)

Мьютексы используются для реализации EREW-алгоритмов, которые рассматриваются в главе 5.

Климан (Klieman), Шах (Shah) и Смаалдерс (Smaalders) утверждали:

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

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

Известно, что статические переменные поддерживают свои значения между вызовами функции. Если некоторая функция содержит статические переменные, то для ее корректного функционирования требуется считывать (и/или изменять) их значения. Если же к такой функции будут обращаться несколько параллельно выполняемых потоков, возникнут условия «гонок». Если функция модифицирует глобальную переменную, то каждый из нескольких потоков, вызывающих функцию, может попытаться модифицировать эту глобальную переменную. Возникновения условий «гонок» также не миновать, если не синхронизировать множество параллельных доступов к глобальной переменной. Например, несколько параллельных потоков могут выполнять функции, которые устанавливают переменную errno. Для некоторых потоков, предположим, эта функция не может выполниться успешно, и переменная errno устанавливается равной сообщению об ошибке [10], в то время как другие потоки выполняются успешно. Если реализация компилятора не обеспечивает потоковую безопасность поддержки переменной errno, то какое сообщение получит поток при проверке состояния переменной errno?

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

getgrgid_r()

getgrnam_r()

getpwuid_r()

sterror_r()

strtok_r()

readdir_r()

rand_r()

ttyname_r()

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

Во всех ситуациях использовать многопоточные версии функций попросту невозможно. В отдельных случаях многопоточные версии конкретных функций недоступны для данного компилятора или среды. Иногда один интерфейс функции не в состоянии сделать ее безопасной. Кроме того, программист может столкнуться с увеличением числа потоков в среде, которая изначально использовала функции, предназначенные для функционирования в однопоточной среде. В таких условиях обычно используются мьютексы. Например, программа имеет три параллельно выполняемых потока. Два из них, thread1 и thread2, параллельно выполняют функцию funcA(), которая не является безопасной для одновременной работы потоков. Третий поток, thread3, выполняет функцию funcB (). Для решения проблемы, связанной с функцией funcA (), возможно, достаточно заключить в защитную оболочку мьютекса доступ к ней со стороны потоков threadl и thread2:

thread1 thread2 thread3

{ { {

lock() lock() funcB()

funcA() funcA() }

unlock() unlock()

} }

При реализации таких защитных мер к функции funcA () в любой момент времени может получить доступ только один поток. Но проблемы на этом не исчерпываются. Если обе функции funcA() и funcB() небезопасны для выполнения потоками, они могут обе модифицировать глобальные или статические переменные. И хотя потоки thread1 и thread2 используют мьютексы для функции funcA (), поток thread3 может выполнять функцию funcB одновременно с любым из остальных потоков. В такой ситуации вполне вероятно возникновение условий «гонок», поскольку функции funcA () и funcB () могут модифицировать одну и ту же глобальную или статическую переменную.

Проиллюстрируем еще один тип условий «гонок», возникающих при использовании библиотеки i ostream. Предположим, у нас есть два потока, А и В, которые выводят данные в стандартный выходной поток, cout, который представляет собой типа ostream. При использовании операторов ">>" и "<<" вызываются методы объекта cout. Вопрос: являются ли эти методы безопасными? Если поток A от правляет сообщение «Мы существа разумные» объекту stdout, а поток В отправляет сообщение «Люди алогичные существа», то не произойдет ли «перемешивание» выходных данных, в результате которого может получиться сообщение вроде такого- " Мы Люди существа алогичные разумные существа»? В некоторых случаях безопасные для потоков функции реализуются как атомные. Атомные функции — это функции, ко торые, если их выполнение началось, не могут быть прерваны. Если операция ">>" для объекта cout реализована как атомная, то подобное «перемешивание» не произойдет. Если есть несколько обращений к оператору ">>", то они будут выполнены последовательно. Сначала отобразится сообщение потока А, а затем сообщение потока В или наоборот, хотя они вызвали функцию вывода одновременно. Это — пример преобразования параллельных действий в последовательные, которое обеспечит безопасность выполнения потоков. Но это не единственный способ обезопасить функцию. Если функция не оказывает неблагоприятного эффекта, она может смешивать свои операции. Например, если метод добавляет или удаляет элементы из структуры, которая не отсортирована, и этот метод вызывают два различных потока, то перемешивание их операций не даст неблагоприятного эффекта.

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

• Ограничить использование всех опасных функций одним потоком.

• Не использовать безопасные функции вообще.

• Собрать все потенциально опасные функции в один набор механизмов синхронизации.

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

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

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

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

• конвейер;

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

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

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

// Листинг 4.5. Подход 1: скелет программы реализации II   модели управляющего и рабочих потоков

//...

pthread_mutex_t Mutex = PTHREAD_MUTEX_INITIALIZER

int AvailableThreads

pthread_t Thread[Max_Threads]

void decrementThreadAvailability(void)

void incrementThreadAvailability(void)

int threadAvailability(void);

// boss thread

{

//...

if(sysconf(_SC_THREAD_THREADS_MAX) > 0){

AvailableThreads = sysconf(_SC_THREAD_THREADS_MAX)

}

else{

AvailableThreads = Default

}

int Count = 1;

loop while(Request Queue is not empty)

if(threadAvailability()){

Count++

decrementThreadAvailability()

classify request

switch(request type)

{

case X : pthread_create(&(Thread[Count])...taskX...)

case Y : pthread_create(&(Thread[Count])...taskY...)

case Z : pthread_create(&(Thread[Count])...taskZ...)

//...

}

}

else{

//free up thread resources

}

end loop

}

void *taskX(void *X)

{

// process X type request

incrementThreadAvailability()

return(NULL)

}

void *taskY(void *Y)

{

// process Y type request

incrementThreadAvailability()

return(NULL)

}

void *taskZ(void *Z)

{

// process Z type request

decrementThreadAvailability()

return(NULL)

}

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

threadAvailability()

incrementThreadAvailability()

decrementThreadAvailability()

В листинге 4.6 содержится псевдокод реализации этих функций.

// Листинг 4.6. Функции, которые управляют возможностью

// создания потоков

void incrementThreadAvailability(void)

{

//...

pthread_mutex_lock(&Mutex)

AvailableThreads++

pthread_mutex_unlock(&Mutex)

}

void decrementThreadAvailability(void)

{

//...

pthread_mutex_lock(&Mutex)

AvailableThreads—

pthread_mutex_unlock(&Mutex)

}

int threadAvailability(void)

{

//...

pthread_mutex_lock(&Mutex)

if(AvailableThreads > 1)

return 1

else

return 0

pthread_mutex_unlock(&Mutex)

}

Ф ункция threadAvailability() возвратит число 1, если максимально допустимое количество потоков для процесса еще не достигнуто. Эта функция опрашивает глобальную переменную ThreadAvailability, в которой хранится число потоков, еще доступных для процесса. Управляющий поток вызывает функцию decrementThreadAvailability(), которая декрементирует эту глобальную переменную до создания им рабочего потока. Каждый рабочий поток вызывает функцию incrementThreadAvailability(), которая инкрементирует глобальную переменную ThreadAvailability до начала его выполнения. Обе функции содержат обращение к функции pthread_mutex_lock () до получения доступа к этой глобальной переменной и обращение к функции pthread_mutex_unlock() после него. Если максимально допустимое количество потоков превышено, управляющий поток может отменить создание потока, если это возможно, или породить другой процесс, если это необходимо. Функции taskX(), taskY () и taskZ () выполняют код, предназначенный для обработки запроса соответствующего типа.

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

// Листинг 4.7. Подход 2: скелет программы реализации . модели управляющего и рабочих потоков

pthread_t Thread[N]

// boss thread

{

pthread_create(&(Thread[1]...taskX...);

pthread_create(&(Thread[2]...taskY...);

pthread_create(&(Thread[3]...taskZ...);

//...

loop while(Request Queue is not empty

get request

classify request

switch(request type)

{

case X :

enqueue request to XQueue

signal Thread[1]

case Y :

enqueue request to YQueue

signal Thread[2]

case Z :

enqueue request to ZQueue

signal Thread[3]

//...

}

end loop

}

void *taskX(void *X)

{

loop

suspend until awaken by boss

loop while XQueue is not empty

dequeue request

process request

end loop

until done

{

void *taskY(void *Y)

{

loop

suspend until awaken by boss

loop while YQueue is not empty

dequeue request

process request

end loop

until done

}

void *taskZ(void *Z)

{

loop

suspend until awaken by boss

loop while (ZQueue is not empty)

dequeue request

process request

end loop

until done

}

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

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

Листинг 4.8. Скелет программы реализации модели  равноправных потоков

pthread_t Thread[N]

// initial thread

{

pthread_create(&(Thread[1]...taskX...);

pthread_create(&(Thread[2]...taskY...);

pthread_create(&(Thread[3]...taskZ...);

//...

}

void *taskX(void *X)

{

loop while (Type XRequests are available)

extract Request

process request

end loop

return(NULL)

}

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

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

// Листинг 4.9. Скелет программы реализации модели конвейера

//...

pthread_t Thread[N]

Queues[N]

// initial thread

{

place all input into stage1's queue

pthread_create(&(Thread[1]...stage1...);

pthread_create(&(Thread[2]...stage2...);

pthread_create(&(Thread[3]...stage3...);

//...

}

void *stageX(void *X)

{

loop

suspend until input unit is in queue

loop while XQueue is not empty

dequeue input unit

process input unit

enqueue input unit into next stage's queue

end loop

until done

return(NULL)

}

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

В модели «изготовитель-потребитель» поток- «изготовитель» готовит данные, «потребляемые» потоком-«потребителем» (причем таких потоков-«потребителей" может быть несколько). Данные хранятся в блоке памяти, разделяемом всеми потока, как изготовителем, так и потребителями. В листинге 4.10 представлен скелет программы реализации модели «изготовитель-потребитель» (эта модель также использовалась в программах 4.5, 4.6 и 4.7).

Листинг 4.10. Скелет программы реализации модели «изготовитель-потребитель»

pthread_mutex_t Mutex = PTHREAD_MUTEX_INITIALIZER

pthread_t Thread[2]

Queue

// initial thread

{

pthread_create(&(Thread[1]...producer...);

pthread_create(&(Thread[2]...consumer...);

//...

}

void *producer(void *X)

{

loop

perform work

pthread_mutex_lock(&Mutex)

enqueue data

pthread_mutex_unlock(&Mutex)

signal consumer

//...

until done

}

void *consumer(void *X)

{

loop

suspend until signaled

loop while(Data Queue not empty)

pthread_mutex_lock(&Mutex)

dequeue data

pthread_mutex_unlock(&Mutex)

perform work

end loop

until done

}

//

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

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

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

// Листинг 4.11 . Объявление и определение многопоточного

// объекта

#include <pthread.h>

#include <iostream>

#include <unistd.h>

void *taskl(void *);

void *task2(void *);

class multithreaded_object {

pthread_t Threadl,

Thread2; public:

multithreaded_object(void);

int cl(void);

int c2(void);

//.. .

);

multithreaded_object::multithreaded_object(void) {

//. . .

pthread_create(&Threadl, NULL, taskl, NULL); pthread_create(&Thread2 , NULL, task2 , NULL);

pthread_join(Threadl, NULL);

pthread_join(Thread2 , NULL);

//. . .

}

int multithreaded_object::cl(void) {

// Выполнение действий,

return(1);

}

int multithreaded_object::c2(void) {

// Выполнение действий,

return(1);

}

multithreaded_object MObj;

void *taskl(void *) {

//...

MObj.cl() ; return(NULL) ;

}

void *task2(void *) {

//...

M0bj.c2(); return(NULL) ;

}

В листинге 4.11 в классе multithread_object объявляются два потока. Они создаются и присоединяются к основному потоку в конструкторе этого класса. Поток Thread1 выполняет функцию task1 (), а поток Thread2 — функцию task2 (). Функции taskl () и task2 () затем вызывают функции-члены глобального объекта MObj.

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

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

Для создания и управления потоками многопоточного приложения можно использовать библиотеку Pthread. Библиотека Pthread опирается на стандартизированный программный интерфейс, предназначенный для создания и поддержки потоков Этот интерфейс определен комитетом стандартов IEEE в стандарте POSIX 1003.1с Сторонние производители при создании своих продуктов должны придерживаться этого стандарта POSIX.

Примечания:

1

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

8

В оригинале - «Therefore, once the thread exits, its resources, namely thread id, can be instantly reused» Exist & exits — все-таки разные слова

9

В оригинале следующее - «If the terminating thread did not make a call to pthread_exit(), then the exit status will be the return value of the function, if it has one; otherwise, the exit status is NULL» Под функцией в данном случае подразумевается функция, составляющая тело потока.

10

коду ошибки, на самом деле