Приложение Б [26]

Имя posix_spawn, posix_spawnp — функции порождения процессов (ADVANCED REALTIME)

Синопсис

SPN #include <spawn.h>

int posix_spawn (

pid_t *restrict pid, const char *restrict path,

const posix_spawn_file_actions_t *file_actions, const posix_spawnattr_t *restrict attrp, char *const argv[restrict], char *const envp[restrict]); int posix_spawnp (

pid_t *restrict pid, const char *restrict file,

const posix_spawn_file_actions_t *file_actions, const posix_spawnattr_t *restrict attrp, char *const argv[restrict], char * const envp[restrict]);

Описание

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

Если в качестве результата этого вызова выполняется С-програ мм а, то она должна быть представлена как функция языка С следующи м образо м: int main (int argc, char *argv[]);

Здесь argc— количество аргу м ентов, а argv— м ассив си м вольных указателей на аргу м енты функции. Кро м е того, следующая пере м енная extern char **environ; должна быть инициализирована как указатель на массив символьных указателей на строки описания конфигурации среды.

Аргумент argv представляет собой массив символьных указателей на строки с завершающим нулем. Последний член этого массива (он не учитывается аргу м ентом argc) должен быть нулевым указателе м. Эти строки составляют список аргу м ентов, доступных для образа нового процесса. Значение эле м ента argrv[0] должно указывать на и м я файла, который связан с образо м процесса, запускае м о г о функцией posix_spawn() или posix_spawnp().

Аргу м ент envp представляет собой м ассив си м вольных указателей на строки с завершающим нулем. Эти строки составляют среду для образа нового процесса. Массив среды завершается нулевым указателем.

Количество байтов, допустимых для обобщенного аргумента сыновнего процесса и списков строк описания конфигурации среды, составляет {ARG_MAX}. В систе м ной доку м е н тации конкретной реализации (с м. то м Base Definitions стандарта IEEE Std 1003.1-2001, Chapter 2, Conformance) должно быть указано, включаются ли в это значение такие служебные данные, как си м волы конца строки, указатели или байты выравнивания.

Ар г у м ент path, передавае м ый функции posix_spawn() , содержит путевое и м я, которое идентифицирует файл образа ново г о процесса.

Пара м етр file , передавае м ый функции posix_spawnp (), используется для формирования путевого имени, которое идентифицирует файл образа нового процесса. Если пара м етр file содержит си м вол «косая черта», то пара м етр file следует рассматривать как путевое имя файла образа нового процесса. В противно м случае префикс пути д ля это г о файла должен быть получен путе м поиска в катало г ах, указанных с по м ощью пере м енной среды PATH (с м. то м Base Definitions стандарта IEEE Std 1003.1-2001, Chapter 8, Environment Variables). Если эта Переменная среды не определена, результаты поиска определяются конкретной реализацией.

Если пара м етр file_actions является нулевы м указателе м, то файловые дескрипторы, открытые в вызываю щ е м процессе, останутся открыты м и и в сыновне м, за исключение м тех из них, для которых установлен фла г «закрытия после выполнения» FD_CLOEXEC (с м. описание функции fcntl()). Для оставшихся открыты м и файловых дескрипторов все атрибуты соответствую щ их описаний открытых файлов, включал блокировки файлов (с м. описание функции fcntl ()), останутся без из м енений.

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

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

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

3. Действия над файлами, заданные объектом действий для порождаемого процесса, должны быть выполнены в порядке их добавления в этот объект.

4.  Любой файловый д ескриптор, у которого установлен флаг FD_CLOEXEC (с м. описание функции fcntl ()), д олжен быть закрыт.

Тип объекта атрибутов posix_spawnattr_t опре д еляется в заголовке <spawn. h>. По м еньшей м ере он д олжен со д ержать атрибуты, опре д еленные ниже.

Если в атрибуте spawn-flags объекта, адресуе м ого пара м етро м attrp, установлен флаг POSIX_SPAWN_SETPGROUP, а атрибут spawn-рдгоиртото же объекта не равен нулю, то группа сыновних процессов д олжна быть за д ана эти м (нену л евы м) атрибуто м объекта.

В качестве специального случал, ес л и в атрибуте spawn-flags объекта, а д ресуемого пара м етро м attrp, установ л ен ф л аг POSIX_SPAWN_SETPGROUP, а атрибут spawn-pgroup того же объекта равен ну л ю, то порож д ае м ый сыновний процесс будет входить в новую группу процессов, идентификатор (ID) которой будет равен значению ID его процесса. Ес л и в атрибуте spawn-flags объекта, адресуе м ого пара м етро м attrp, ф л аг POSIX_SPAWN_SETPGROUP не установ л ен, то новый сыновний процесс наслелует группу ро д ите л ьского процесса.

PS Если в атрибуте spawn-flags объекта, а д ресуе м ого пара м етро м attrp, установлен флаг POSIX_SPAWN_SETSCHEDPARAM, но флаг POSIX_SPAWN_SETSCHEDULER не установлен, то образ нового процесса будет изначально обладать стратегией планирования вызывающего процесса с пара м етра м и планирования, за д анны м и в атрибуте spawn-schedparamoбъeкта, адресуемого пара м етро м attrp.

Если в атрибуте spawn-flags объекта, адресуе м ого пара м етро м attrp, установлен флаг POSIX_SPAWN_SETSCHEDULER (независи м о от установки флага POSIX_SPAWN_SETSCHEDPARAM), то образ нового процесса будет изначально обладать стратегией планирования, заданной атрибуто м spawn-schedpolicy объекта, адресуе м ого пара м етро м attrp, и пара м етра м и планирования, заданны м и в атрибуте spawn-schedparamToro же объекта.

Флаг POSIX_SPAWN_RESETIDS в атрибуте spawn-flags объекта, адресуе м ого пара м етро м attrp, обусловливает значение ID эффективного пользователя сыновнего процесса. Если этот флаг не установлен, сыновний процесс наслелует ID эффективного пользователя родительского процесса. Если этот флаг установлен, ID эффективного пользователя сыновнего процесса должен быть установлен равны м значению ID реального пользователя родительского процесса. В любо м случае, если установлен бит режи м а «set-user-ID» д ля файла образа нового процесса, ID эффективно г о пользователя сыновне г о процесса при м ет значение, равное значению ID владельца этого файла до того, как начнет выполняться образ нового процесса.

Флаг POSIX__SPAWN_RESETIDS в атрибуте spawn-flags объекта, адресуе м ого пара м етро м attrp, также обусловливает значение ГО эффективной группы сыновне г о процесса Если этот фла г не установлен, сыновний процесс наслелует ID эффективной группы родительско г о процесса. Если этот флат установлен, ID эффективной группы сыновнего процесса должен быть установлен равны м значению ID реальной группы родительского процесса. В любо м случае, если установлен бит режи м а «set-group-ID» д л я файла образа нового процесса, ID эффективной группы сыновнего процесса примет значение, равное значению ID группы этого файла до того, как начнет выполняться образ нового процесса.

Если в атрибуте spawn-flags объекта, адресуемого параметром attrp, установлен флаг POSIX_SPAWN_SETSIGMASK, то сыновний процесс изначально будет и м еть м аску сигнала, заданную в атрибуте spawn-sigmask объекта , адресуе м ого пара м етро м attrp .

Если в атрибуте spawn-flags объекта, адресуе м ого пара м етро м attrp, установлен флаг POSIX_SPAWN_SETSIGDEF, то сигналы, заданные в атрибуте spawn-sigdefault того же объекта, будут установлены равны м и их действия м по у м олчанию в сыновне м процессе. Сигналы, установленные равны м и действия м по у м олчанию в родительско м процессе, должны быть установлены равны м и действия м по у м олчанию в сыновне м процессе.

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

За исключение м сигнала SIGCHLD, сигналы, которые д олжны игнорироваться образо м вызываю щ его процесса, д олжны игнорироваться сыновни м процессо м, если не опре д елено иное посредство м флага POSIX_SPAWN_SETSIGDEF, установленного в атрибуте spawn-flags объекта, адресуе м ого пара м етро м attrp, и сигнала SIGCHLD, обозначенного в атрибуте spawn-sigdefault того же объекта.

Если сигнал SIGCHLD установлен как игнорируемый вызывающим процессом, точно не установлено, должен ли сигнал SIGCHLD игнорироваться сыновним процессом или он будет установлен равным действию по умолчанию в сыновнем процессе, если не определено иное посредством флага POSIX_SPAWN_SETSIGDEF, установленного в атрибуте spawn-flags объекта, адресуемого параметром attrp, и сигнала SIGCHLD, обозначенного в атрибуте spawn_sigdefault того же объекта.

Если указатель attrp содержит значение NULL, используются значения по умолчанию.

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

THR Запускаются ли обработчики разветвлений при вызове функций posix_spawn () или posix_spawnp (), определяется конкретной реализацией.

Возвращаемые значения

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

Ошибки

Вызовы функций posix_spawn() и posix_spawnp() могут оказаться неудачными, если:

[EINVAL] значение, за д анное пара м етро м file_actions или пара м етро м attrp, не д ействительно.

Если ошибка возникла после того, как вызывающий процесс успешно вернулся из функции posix_spawn () или posix_spawnp (), то сыновний процесс может завершиться со стагусом выхода (exit status), равным значению 127.

Если неудачный исход функции posix_spawn () или posix_spawnp () вызван одной из причин, которые бы привели к отказу функции fork () или одной из функций семейства exec, то возвращаемое значение ошибки будет соответствовать описанию для функций fork () и exec соответственно (или, если ошибка возникнет после того, как вызывающий процесс успешно вернется, сыновний процесс завершится со статусом выхода, равным значению 127).

Если в атрибуте spawn-flags объекта, а д ресуе м ого пара м етро м attrp, установлен флаг POSIX_SPAWN_SETPGROUP, а функция posix_spawn() или posix_spawnp() потерпела неу д алу при из м енении группы сыновнего процесса, то возвра щ ае м ое значение ошибки бу д ет соответствовать описанию д ля функции setpgid () (или, если ошибка возникнет после того, как вызываю щ ий процесс успешно вернется, сыновний процесс завершится со статусо м выхо д а, равны м значению 127).

PS   Если в атрибуте spawn-flags объекта, а д ресуе м ого пара м етро м attrp, установлен флаг POSIX_SPAWN_SETSCHEDPARAM, а флаг POSIX_SPAWN_SETSCHEDULER не установлен, то, если неу д ачный исхо д функции posix_spawn() или posix_spawnp() вызван о д ной из причин, которые бы привели к отказу функции sched_setparam(), возвра щ ае м ое значение ошибки бу д ет соответствовать описанию д ля функции sched_setparam() (или, если ошибка возникнет после того, как вызываю щ ий процесс успешно вернется, сыновний процесс завершится со статусо м выхо д а, равны м значению 127).

Если в атрибуте spawn-flags объекта, а д ресуе м ого пара м етро м attrp, установлен флаг POSIX_SPAWN_SETSCHEDULER, и если неу д ачный исхо д функции posix_spawn() или posix_spawnp() вызван о д ной из причин, которые бы привели к отказу функции sched_setscheduler(), возвра щ аемое значение ошибки бу д ет соответствовать описанию для функции sched_setscheduler () (или, если ошибка возникнет после того, как вызываю щ ий процесс успешно вернется, сыновний процесс завершится со статусо м выхода, равны м значению 127). Если аргу м ент file_actions не равен значению NULL и определяет для выполнения любое из действий close, dup2 или орел, и если неудачный исход функции posix_spawn() или posix_spawnp() вызван одной из причин, которые бы привели к отказу функций close(), dup2() или open(), возвра щ ае м ое значение ошибки будет соответствовать описанию для функций close (), dup2 () и open() соответственно (или, если ошибка возникнет после того, как вызываю щ ий процесс успешно вернется, сыновний процесс завершится со статусо м выхода, равны м значению 127). Действие, связанное с открытие м файла, м ожет са м о по себе выразиться в любой из ошибок, описанных для функций close () или dup2 (), по м и м о тех, что описаны для функции open ().

Примеры

Отсутствуют.

Замечания по использованию

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

Логическое обоснование

Функция posix_spawn () и ее «близкая родственница» функция posix_spawnp () были введены для преодоления следующих ощутимых трудностей использования функции fork (): функцию fork () сложно (или невозможно) реализовать без обмена (подкачки) или динамической трансляции адреса.

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

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

• Создание процессов с помощью библиотеки POSIX не требует трансляции адресов или иных услуг, связанных с MMU (memory management unit — блок управления памятью).

Таким образом, библиотека POSIX использует примитивы создания процессов и выполнения файлов, которые могут быть эффективно реализованы без трансляции адресов или иных MMU-процедур.

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

Такая роль функций posix_spawn() и posix_spawnp() оказала влияние на их API-интерфейс. Здесь не было попытки обеспечить полную функциональность пар fork()/exec, при использовании которых между созданием сыновнего процесса и выпол н ение м образа нового процесса разрешаются любые определенные пользователе м операции; ведь Любая попытка достичь такого уровня потребовала бы пара м етрического задания используе м ого языка програ мм ирования. Поэто м у функции posix_spawn () и posix_spawnp () представляют собой базовые операции создания процессов, подобные процедура м Start_Process и Start_Process_Search из пакета POSIX_Process_Primitives в языке программирования Ada, а также другим операциям, предусмотренным во многих операционных системах (но не UNIX), оснащенных POSIX -расширениями.

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

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

Управления маской сигналов и установкой сигналов по умолчанию вполне достаточно для поддержки реализации функции system(). Несмотря на то что поддержка функции system() не является одной из явных целей для функций posix_spawn() и posix_spawnp (), все же эта поддержка составляет не менее 50% от общей «суммы целей».

Намерение состоит в том, что обычное насле д ование файлового д ескриптора через функцию fork (), последующий результат за д анных д ействий над файлами и обычное наследование файлового дескриптора через одну из функций семейства exec должно полностью определять наследование открытых файлов. Реализации не нужно принимать никаких решений относительно набора открытых дескрипторов файлов в начале выполнения образа сыновнего процесса, эти решения уже были приняты инициатором вызова функции и выражены в виде набора открытых д ескрипторов файлов и их флагов FD_CLOEXEC в м о м ент вызова, а также объекта действий над файлами, заданного в этом вызове. Мы убеждены, что в случаях, когда POSIX -примитивы языкa Ada (Start_Process) реализованы в библиотеке, этот метод управления наследованием файловых дескрипторов может быть реализован очень легко.

Мы м оже м и д ентифицировать ря д пробле м, связанных с использование м функций posix_spawn( ) и posix_spawnp (), но на м неизвестно решение с м еньши м количество м пробле м. Мо д ификация сре д ы д ля атрибутов сыновнего процесса, которая не определяется с по м о щ ью аргу м ентов attrp или file_actions, д олжна быть выполнена в ро д ительско м процессе, а поскольку ро д ительский процесс обычно стремится сохранить свой контекст, это более затратно, чем аналогичное поведение, достигаемое с помощью функций fork () /exec. Кроме того, сложно модифицировать на время среду многопоточного процесса, поскольку для безопасного изменения среды все потоки должны быть согласованы. Однако на эти затраты еще можно было бы пойти, применяя вызовы тех функций posix_spawn () и posix_spawnp (), которые используют дополнительные возможности. А поскольку расширенные модификации— это исключение, а не правило, и они особенно непригодны в критическом ко времени выполнения коде, сохранение большинства «рычагов управления» средой вне функций posix_spawn () и posix_spawnp () возлагается на соответствующее проектирование.

Функции posix_spawn() и posix_spawnp () не обладают всей полнотой власти, которая характерна для функций fork () / exec. И такой эффект вполне ожидаем. Функция fork () — чрезвычайно мощная. Мы и не надеялись скопировать все ее возможности в простой и быстрой функции, не предъявляя специальных требований к оборудованию. Важно то, что функции posix_spawn () и posix_spawnp () очень близки к средствам создания процессов во многих операционных системах, отличных от UNIX.

Требования

К реализации функций posix_spawn() и posix_spawnp() предъявляются следующие требования.

• Они должны быть реализованы без использования MMU (memory management unit — блок управления памятью) или какого-то иного специального оборудования.

• Они должны быть совместимы с существующими POSIX -стандартами. Дополнительные требования таковы.

• Они должны быть эффективными.

• Их способность по замещению функции fork () (в обычных условиях) должна составлять не меньше 50%.

• Система, в которой реализованы функции posix_spawn () и posix_spawnp (), но не реализована функция fork (), должна иметь достаточную эффективность, по крайней мере для приложений реального времени.

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

Двухвариантный синтаксис

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

Различий в списках параметров между функциями posix_spawn () и posix_spawnp () практически нет; при использовании функции posix_spawnp() второй параметр интерпретируется более сложно, чем при использовании функции posix_spawn ().

Совместимость с POSIX.5 (Ada)

Процедуры Start_Process и Start_Process_Search из пакета привязки языка Ada POSIX_Process_Primitives к POSIX.1 . инкапсулируют действия функций fork() и ехес практически так же, как это делают функции posix_spawn() и posix_spawnp(). Первоначально, придерживаясь цели более простого подхода, разработчики стандарта ограничили возможности функций posix_spawn() и posix_spawnp() подмножеством возможностей, присущих процедурам Start_Process и Start_Process_Search, отказавшись от поддержки конкретных нестандартных средств. Но на основе пожеланий группы приема стандарта усовершенствовать отображение дескрипторов файлов или совсем отказаться от них, а также по рекомендации членов рабочей группы Ada Language Bindings разработчики стандарта решили, что функции posix_spawn() и posix_spawnp() должны быть в достаточной степени эффективными для реализации возможностей процедур Start_Process и Start_Process_Search. Мы исходили из того, что если привязка языка Ada к такому базовому варианту уже была одобрена в качестве стандарта IEEE, то вряд ли не будут одобрены эквивалентные части С-привязки. Среди возможностей, реализованных функциями posix_spawn() и posix_spawnp(), можно насчитать только следующие три пункта, которые не обеспечивались процедурами Start_Process и Start_Process_Search: необязательное задание идентификационного номера группы сыновних процессов, набор сигналов, подлежащих стандартной обработке в сыновнем процессе, а также стратегия планирования (и ее параметры).

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

Группа процессов

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

Потоки

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

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

Асинхронное уведомление об ошибках

Библиотечная реализация функций posix_spawn () или posix_spawnp () не позволяет выявить все возможные ошибки до создания сыновнего процесса. Стандарт IEEE Std 1003.1-2001 обеспечивает возможность индикации ошибок, возвращаемых из сыновнего процесса, которому не удалось успешно завершить операцию создания, с помощью специального статуса выхода, который можно обнаружить, используя значение статуса, возвращаемое функциями wait () и waitpid ().

Интерфейс stat_val и макрос, используемый для его интерпретации, не совсем подходят для цели возврата API-ошибок, но они являются единственным способом, доступным для библиотечной реализации. Таким образом, реализация может заставить сыновний процесс завершиться со статусом выхода 127 в случае любой ошибки, выявленной во вре м я порождения процесса после успешного завершения функции posix_spawn() или posix_spawnp().

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

Восьми бит статуса выхода сыновнего процесса, доступность которых для ожидающего родительского процесса гарантирована стандартом IEEE Std 1003.1-2001, недостаточно для устранения неоднозначности ошибок порождения процесса, которые может возвратить образ любого процесса. Требуется, чтобы в значении stat_val никакие другие биты статуса выхода не были видимы, поэтому упомянутые выше макросы не поддаются строгой реализации на библиотечном уровне. Резервирование значения статуса выхода 127 для таких ошибок порождения процессов согласуется с использованием этого значения функциями system() и popen() при пропадании сигналов в этих операциях, которые возникают после завершения функции, но перед тем, как системная оболочка сможет их отработать. Статус выхода 127 уникальным образом не идентифицирует этот класс ошибок и не предоставляет никакой детальной информации о природе сбоя. Обратите внимание на то, что разрешается (и даже поощряется) «ядерная» реализация функций posix_spawn() и posix_spawnp() с обеспечением возврата любых возможных ошибок в виде значений, возвращаемых этой функцией, тем самым предоставляя для родительского процесса более детальную информацию о происшедших сбоях.

Таким образом, для выделения асинхронных ошибок при выполнении функций posix_spawn() или posix_spawnp() упомянутые выше макросы не используются. О возможных ошибках, обнаруженных в контексте сыновнего процесса до того, как выполнится образ нового процесса, уведомление происходит путем установки статуса выхода сыновнего процесса равным значению 127. Вызывающий процесс для выявления сбоев при порождении процессов может использовать макросы WIFEXITED HWEXITSTATUS и значение stat_val, сохраненное функциями wait() или waitpid(), в тех случаях, когда другие значения статуса, с которыми может завершиться образ сыновнего процесса (до того, как родительский процесс сможет окончательно определить, что образ сыновнего процесса начал выполняться), отличаются от статуса выхода, равного числу 127.

Будущие направления

Отсутствуют.

Смотри также

alarm(), chmod(), close (), dup(), exec, exit (), fcntl (), fork(), kill (), open (),posix_spawn_file_actions_addclose(), posix_spawn_file_actions_adddup2(), posix_spawn_file_actions_addopen(), posix_spawn_file_actions_destroy() , <REFERENCE UNDEFINED> (posix_spawn_file_actions_init), posix_spawnattr_destroy(), posix_spawnattr_init(), posix_spawnattr_getsigdefault(), posix_spawnattr_getflags(), posix_spawnattr_getpgroup(), posix_spawnattr_getschedparam(), posix_spawnattr_getschedpolicy(), posix_spawnattr_getsigmask (), posix_spawnattr_setsigdefault (), posix_spawnattr_setflags(), posix_spawnattr_setpgroup(), posix_spawnattr_setschedparam (), posix_spawnattr_setschedpolicy (), posix_spawnattr_setsigmask (), sched__setparam (), sched_setscheduler (), setpgid (), setuid (), stat (), times (), wait ()

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 6, основанием послужил стандарт IEEEStdl003.1d-1999.

Применяется интерпретация IEEE PASC Interpretation 1003.1 #103, которая указывает, что в пункте 2 действия, соответствующие установкам сигналов по умолчанию, изменены так же, как маска сигналов.

При м еняется интерпретация IEEE PASC Interpretation 1003.1 #132.

Имя

posix_spawn_file_actions_addclose, posix_spawn_file_actions_addopen— функции внесения в объект действий над файла м и действия «закрыть файл» (или «открыть файл») (ADVANCED REALTIME).

Синопсис

SPN #include <spawn.h>

int posix__spawn_file_actions_addclose (

posix_spawn_file_actions_t *file_actions, int fildes); int posix_spawn_file_actions_addopen (

posix_spawn_file_actions_t *restrict file_actions, int fildes,

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

Описание

Эти функции добавляют в объект действий над файла м и действие «закрыть файл» (или «открыть файл») или удаляют соответствую щ ее действие из это г о объекта.

Объект действий над файла м и и м еет тип posix_spawn_file_actions_t (который определен в за г оловке <spawn.h>) и используется для задания последовательности действий, подлежа щ их выполнению функция м и posix_spawn() или posix_spawnp() с целью получения для сыновне г о процесса м ножества открытых файловых дескрипторов в соответствии с м ножество м открытых файловых дескрипторов родительско г о процесса. Стандарт IEEE Std 1003.1-2001 не определяет для типа posix_spawn_file_actions_t операторы сравнения или присваивания.

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

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

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

Строка, адресуе м ая пара м етро м path, копируется функцией posix_spawn_file_actions_addopen().

Возвращаемые значения

При успешном завершении эти функции возвращают нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Эти функции завершатся неудачно, если:

[EBADF] значение, заданное пара м етро м fildes, отрицательно либо больше или равно значению {OPEN_MAX}.

Выполнение этих функций м ожет завершиться неудачно, если: [EINVAL] значение, заданное пара м етро м file_actions, недопусти м о;

[ENOMEM] для расширения содержи м ого объекта действий над файлами недостаточно су щ ествую щ ей па м яти.

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

Примеры

Отсутствуют.

Замечания по использованию

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

Логическое обоснование

Объект действий над фай л а м и м ожно инициализировать с по м о щ ью упорядоченной пос л едовате л ьности операций close (), dup2 () и open (), предназначенной д л я испо л ьзования функция м и posix_spawn () и л и posix_spawnp () с це л ью получения м ножества открытых фай л овых дескрипторов, унас л едованных порожденны м процессо м от своего родите л я, и м ею щ е г о собственное м ножество открытых фай л овых дескрипторов в м о м ент вызова функции posix_spawn () и л и posix_spawnp (). Д л я реор г анизации фай л овых дескрипторов бы л о пред л ожено о г раничиться то л ько операция м и close () и dup2 (), а для то г о, чтобы порожденный процесс получил «в наследство» открытые файлы, м ожно посгупить дву м я способа м и: либо заставить вызывающий процесс открывать их перед вызово м функции posix_spawn() или posix_spawnp() (и закрывать их пото м), либо передавать и м ена нужных файлов в порожденный процесс (в аргу м енте argv), чтобы он м ог их открыть са м остоятельно. Разработчики стандарта реко м ендовали использовать на практике один из этих двух способов, поскольку детализированный статус ошибки в случае сбоя при выполнении операции открытия файла всегда доступен для приложения. Но разработчики стандарта по следую щ и м причина м все же считают воз м ожны м разрешить включение в объект действий над файла м и операцию open.

1. Это согласуется с эквивалентной функциональностью библиотеки POSIX .5 (Ada).

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

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

Относительно приведенного выше п. 2 заметим, что действие «открыть файл» создает для функций posix_spawn () и posix_spawnp () те же возможности, что и операторы перенаправления для функции system(), но только без промежуточного выполнения оболочки. Например, так: system («myprog <filel 3<file2»);

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

Кроме того, если родительский процесс выполняется из файла, для которого установлен бит режима «set-user-id» (идентификационный номер пользователя установлен) и в атрибутах порожденного процесса установлен флаг POSIX_SPAWN_RESETIDS, то файл, созданный в родительско м процессе, получит (воз м ожно, некорректно) в качестве владельца родительский ID эффективного пользователя, в то вре м я как файл, созданный действие м open() при выполнении функции posix_spawn() или posix_spawnp(), получит в качестве владельца реальный ID родительского процесса; при это м операция open, выполненнал родительски м процессо м, м ожет успешно открыть файл, к которо м у реальный пользователь не должен и м еть доступ, или неудачно открыть (т.е. не открыть) файл, к которо м у реальный пользователь должен и м еть доступ.

Преобразование файловых дескрипторов

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

Одним из членов рабочей группы Ada Language Bindings было отмечено, что принятое в языке Ada семейство POSIX-примитивов Start_Process использует м ножество действий (задавае м ое инициаторо м вызова функции), чтобы изменить общепринятую семантику функций fork () /exec с целью наследования файловых дескрипторов довольно гибким способом, и пока никаких проблем не возникало, поскольку все бремя определения, как достичь конечного преобразования файловых дескрипторов, полностью лежит на приложении. Более того, хотя интерфейс, связанный с действиями над файлами, выглядит устрашающе сложным, в действительности он довольно прост для реализации либо в библиотеке, либо в ядре.

Будущие направления

Отсутствуют.

Смотри также

close (), dup (), open (), posix_spawn (), posix_spawn_file_actions_adddup2 (),

posix_spawn_file_actions_destroy (), posix_spawnp (), том Base Definitions стандарта IEEE Std 1003.1-2001, < spawn. h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 6, основание м послужил стандарт IEEEStd 1003.1d-1999.

При м еняется интерпретация IEEE PASC Interpretation 1003.1 #105, со г ласно которой в раздел «Описание» было внесено дополнение о то м, что строка, адресуе м ал пара м етро м path, копируется функцией posix_spawn_file_actions_addopen ().

Имя

posix_spawn_file_actions_adddup2— функция внесения в объект действий над файла м и действия dup2 (ADVANCED REALTIME).

Синопсис

SPN #include <spawn.h>

int posix_spawn_file_actions_adddup2 (

posix_spawn_file_actions_t * file_aсtions, int fildes, int newfildes);

Описание

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

Объект действий над файла м и порожденного процесса определяется в описании функции posix_spawn_file_actions_addclose().

Возвращаемое значение

При успешно м завершении функция posix_spawn_file_actions_adddup2() возвра щ ает нулевое значение; в противно м случае — код ошибки, обозначаю щ ий ее характер.

Ошибки

Функция posix_spawn_file_actions_adddup2 () завершится неудачно, если:

[EBADF] значение, заданное пара м етро м fildes или newfildes, отрицательно либо больше или равно значению {0PEN_MAX};

[EN0MEM] для расширения содержи м ого объекта действий над файла м и недостаточно су щ ествую щ ей па м яти.

Выполнение фу н кции posix_spawn_file_actions_adddup2() м ожет завершиться неудачно, если:

[EINVAL] значение, заданное пара м етро м file_actions, недопусти м о.

Не считается ошибкой, если в качестве значения аргу м ента fildes, передавае м ого функции posix_spawn_file_actions_adddup2(), указан файловый дескриптор, для которо г о заданная операция не м ожет быть выполнена во вре м я вызова. Любая подобная ошибка будет обнаружена, ко г да соответствую щ ий объект действий над файла м и позже будет использован при выполнении функции posix_spawn () или posix_spawnp ().

Примеры

Отсутствуют.

Замечания по использованию

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

Логическое обоснование

С м отрите раздел «Ло г ическое обоснование» в описании функции posix_spawn__file_actions_addclose().

Будущие направления

Отсутствуют.

Смотри также

dup (), posix_spawn (), posix_spawn_file_actions_addclose (), posix_spawn_file_actions_destroy (), posix_spawnp (), том Base Definitions стандарта IEEE Std 1003.1-2001, <spawn. h>.

Последовательность внесения изменений

Функция впервые реализована в выпуске Issue 6, основание м послужил стандарт IEEEStdl003.1d-1999.

При м еняется интерпретация IEEE PASC Interpretation 1003.1 #104, в которой указывается, что ошибка [EBADF], по м и м о аргу м ента fildes, м ожет быть при м ени м а к аргу м енту newfildes.

Имя

posix_spawn_file_actions_destroy, posix_spawn_file_actions_init — функции разрушения и инициализации объекта действий над файла м и для порожде н но г о процесса (ADVANCED REALTIME).

Синопсис

SPN #include <spawn.h>

int posix_spawn_file_actions_destroy (posix_spawn_file_actions_t *file___actions) ;

int posix_spawn_file_actions_init (posix_spawn_file_actions_t *file_actions);

Описание

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

Функция posix_spawn_file_actions_init () используется для инициализации объекта, адресуемого параметром file_actions; после ее при м енения объект не будет содержать никаких действий, предназначенных для выполнения над файла м и при вызове функций posix_spawn () или posix_spawnp ().

Объект действий над файла м и порожденно г о процесса определяется в описании функции posix_spawn_file_actions_addclose(). Результат инициализации уже инициализированно г о объекта действий над файла м и не определен.

Возвращаемые значения

При успешно м завершении эти функции возвра щ ают нулевое значение; в противно м случае — код ошибки, обозначаю щ ий ее характер.

Ошибки

Функция posix_spawn_file_actions_init () завершится неудачно, если:

[EN0MEM]  для и ниц и ализаци и объекта действий над файла м и недостаточно су щ ествую щ ей па м яти.

Функция posix_spawn_file_actions_destroy() м ожет завершиться неудачно, если:

[EINVAL]

значение, заданное пара м етро м file_actions, недопусти м о.

Примеры

Отсутствуют.

Замечания по использованию

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

Логическое обоснование

С м отрите раздел «Логическое обоснование» в описании функции posix_spawn_file_actions_addclose().

Будущие направления

Отсутствуют.

Смотри также

posix_spawn (), posix_spawnp (), том Base Definitions стандарта IEEE Std 1003.1-2001, <spawn.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 6, основание м послужил стандарт IEEE Std 1003.1d-1999.

В разделе «Синопсис» включение заголовка <sys/types.h> больше не требуется.

Имя

posix_spawnattr_destroy, posix_spawnattr_init— функции разрушения и инициализации объекта атрибутов порожденно г о процесса (ADVANCED REALTIME).

Синопсис

SPN #include <spawn.h>

int posix_spawnattr_destroy (posix_spawnattr_t *attr); int posix_spawnattr_init (posix_spawnattr_t *attr);

Описание

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

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

Объект атрибутов порожденного процесса имеет тип posix_spawnattr_t (определен в заголовке <spawn.h>) и используется для задания наследования атрибутов процесса при выполнении операции порождения процесса. Для типа posix_spawnattr_t операторы сравнения и присваивания стандарт IEEE Std 1003.1-2001 не определяет.

Для каждой реализации должны быть описаны отдельные атрибуты, которые она использует, и их стандартные значения, если они не определены стандартом IEEE Std ЮОЗ.1-2001. Атрибуты, не определенные стандартом IEEE Std 1003.1-2001, их стандартные значения и имена соответствующих функций чтения и записи этих атрибутов определяются конкретной реализацией.

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

Возвращаемые значения

При успешно м завершении функции posix_spawnattr_destroy() и posix_spawnattr_init() возвра щ ают нулевое значение; в противно м случае — ко д ошибки, обозначаю щ ий ее характер.

Ошибки

Функция posix_spawnattr_init () завершится неудачно, если:

[ ENOMEM ] для инициализации объекта атрибутов недостаточно существующей памяти.

Функция posix_spawnattr_destroy () м ожет завершиться неудачно, если:

[EINVAL ] з н ачение, заданное пара м етро м attr, недопусти м о.

Примеры

Отсутствуют.

Замечания по использованию

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

Логическое обоснование

Исходный интерфейс, предложенный в стандарте IEEE Std 1003.1-2001, определял атрибуты, наследуемые при выполнении операции порождения процесса, в виде структуры. Чтобы иметь возможность выделить некоторые необязательные атрибуты в отдельные опции (например, атрибуты spawn-schedparamn spawn-schedpolicy относятся к опции Process Scheduling), а также с целью расширяемости и совместимости с более новыми POSIX-интерфейсами, для интерфейса атрибутов был изменен тип данных. Этот интерфейс в настоящее время состоит из типа posix_spawnattr_t, представляющего объект атрибутов порожденного процесса, и соответствующих функций, которые позволяют инициализировать или разрушить этот объект атрибутов, а также установить или получить значение каждого отдельного атрибута. Несмотря на то что новый объектно-ориентированный интерфейс более сложен, чем исходнал структура, его проще использовать, легче наращивать и реализовывать.

Будущие направления

Отсутствуют.

Смотри также

posix_spawn (), posix_spawnattr_getsigdefault (), posix_spawnattr_getflags (), posix_spawnattr_getpgroup (), posix_spawnattr_getschedparam(), posix_spawnattr_getschedpolicy (), posix_spawnattr_getsigmask(),posix_spawnattr_setsigdefault(), posix_spawnattr_setflags(), posix_spawnattr_setpgroup(), posix_spawnattr_setsigmask(), posix_spawnattr_setschedpolicy(), posix_spawnattr_setschedparam (), posix_spawnp (), то м Base Definitions стан д арта IEEEStd 1003.1-2001, <spawn.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 6, основанием послужил стандарт IEEE Std 1003.1d-1999.

При м еняется интерпретация IЕЕЕ PASC Interpretation 1003.1 #106, в которой отмечается, что результат инициализации уже инициализированного объекта атрибутов не определен.

Имя

posix_spawnattr_getflags, posix_spawnattr_setflags— функции считывания и установки атрибута spawn-flags из объекта атрибутов порож д енного процесса (ADVANCED REALTIME).

Синопсис

SPN #include < spawn.h>

int posix_spawnattr_getflags (const posix_spawnattr_t *restrict attr, short *restrict flags);

int posix_spawnattr_setflags (posix_spawnattr_t *attr, short flags);

Описание

Функция posix_spawnattr_getflags () пре д назначена д ля получения значения атрибута spawn-flags из объекта атрибутов, адресуе м ого пара м етро м attr.

Функция posix_spawnattr_setflags () пре д назначена д ля установки значения атрибута spawn-flags в инициализированно м объекте атрибутов, адресуе м о м пара м етро м аttr.

Атрибут spawn-flags используется д ля обозначения того, какие атрибуты процесса должны быть изменены в образе нового процесса при вызове функции posix_spawn() или posix_spawnp(). Этот атрибут представляет собой результат применения поразрядной операции включающего ИЛИ к некоторому числу (которое может быть нулевым) следующих флагов:

POSIX_SPAWN_RESETIDS

POSIX_SPAWN_SETPGROUP

POSIX_SPAWN_SETSIGDEF

POSIX_SPAWN_SETSIGMASK

PS

POSIX_SPAWN_SETSCHEDPARAM

POSIX_SPAWN_SETSCHEDULER

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

Возвращаемые значения

При успешном выполнении функция posix_spawnattr_getflags () возвращает нулевое значение и сохраняет значение атрибута spawn-flags из объекта атрибутов, адресуе м ого пара м етро м attr, в объекте, адресуе м о м пара м етро м flags; в противном случае возвращается код ошибки, обозначающий ее характер.

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

Ошибки

Эти функции м огут завершиться неу д ачно, если: [EINVAL]  значение, заданное пара м етро м attr, не д опусти м о.

Функция posix_spawnattr__setflags () м ожет завершиться неу д ачно, если:

[ EINVAL ]  устанавливаемое значение атрибута недопустимо.

Примеры

Отсутствуют.

Замечания по использованию

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

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

posix_spawn (), posix_spawnattr_destroy (), posix_spawnattr_init (), posix_spawnattr_getsigdefault (), posix_spawnattr_getpgroup (), posix_spawnattr_getschedparam(), posix_spawnattr_getschedpolicy(), posix_spawnattr_getsigmask (), posix_spawnattr_setsigdefault (), posix_spawnattr_setpgroup (), posix_spawnattr_setschedparam(), posix_spawnattr_setschedpolicy (), posix_spawnattr_setsigmask (), posix_spawnp (), том Base Definitions стан д арта IEEE Std 1003.1-2001, <spawn. h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 6, основанием послужил стан д арт IEEE Std 1003.1d-1999.

Имя

posix_spawnattr_getpgroup, posix_spawnattr_setpgroup— функции считывания и установки атрибута spawn-pgroup из объекта атрибутов порожденного процесса (ADVANCED REALTIME).

Синопсис

SPN #include <spawn.h>

int posix_spawnattr_getpgroup (

const posix_spawnattr_t *restrict attr,

pid_t *restrict pgroup); int posix_spawnattr_setpgroup (posix_spawnattr_t *attr,

pid_t pgroup) ;

Описание

Функция posix_spawnattr_getpgroup() предназначена для получения значения атрибута spawn-pgroup из объекта атрибутов, адресуе м ого пара м етро м attr.

Функция posix_spawnattr_setpgroup () позволяет установить атрибут spawn-pgroup в инициализированно м объекте атрибутов, адресуе м о м пара м етро м attr.

Атрибут spawn-pgroup представляет группу процессов, к которой при выполнении операции порождения процесса присоединяется новый процесс (если в атрибуте spawn-flags установлен флаг POSIX_SPAWN_SETPGROUP). По у м олчанию значение этого атрибута равно нулю.

Возвращаемые значения

При успешном выполнении функция posix_spawnattr_getpgroup () возвращает нулевое значение и сохраняет значение атрибута spawn-pgroup из объекта атрибутов, адресуемого параметром attr, в объекте, адресуемом параметром pgroup\ в противном случае возвращается код ошибки, обозначающий ее характер.

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

Ошибки

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

[EINVAL]  значение, заданное пара м етро м attr, недопусти м о.

Функция posix_spawnattr_setgroup () м ожет завершиться неудачно, если:

[ EINVAL ]  устанавливае м ое значение атрибута недопусти м о.

Примеры

Отсутствуют.

Замечания по использованию

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

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

posix_spawn(), posix_spawnattr_destroy(),posix_spawnattr_init(), posix_spawnattr_getsigdefault(), posix_spawnattr_getflags(), posix_spawnattr_getschedparam(), posix_spawnattr_getschedpolicy(), posix_spawnattr_getsigmask(), posix_spawnattr_setsigdefault(), posix_spawnattr_setflags (), posix_spawnattr_setschedparam(), posix_spawnattr_setschedpolicy(), posix_spawnattr_setsigmask(), posix_spawnp (), том Base Deflnitions стан д арта IEEE Std 1003.1-2001, <spawn.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 6, основанием послужил стандарт IEEE Std 1003.1d-1999.

Имя

posix_spawnattr_getschedparam, posix_spawnattr_setschedparam

функции считывания и установки атрибута spawn-schedparam из объекта атрибутов порожденного процесса (ADVANCED REALTIME).

Синопсис

SPNPS #include <spawn.h>

#include <sched.h>

int posix_spawnattr_getschedparam (const posix_spawnattr_t *restrict attr, struct sched_param *restrict schedparam) ;

int posix_spawnattr_setschedparam (posix_spawnattr_t *restrict attr, const struct sched_param *restrict schedparam) ;

Описание

Функция posix_spawnattr_getschedparam() предназначена для получения значения атрибута spawn-schedparamn3 объекта атрибутов, адреcуемого параметром attr.

Функция posix_spawnattr_setschedparam() позволяет установить атрибут spawn-schedparam в инициализированно м объекте атрибутов, адресуе м о м пара м етро м аttr.

Атрибут spawn-schedparam представляет пара м етры стратегии планирования, присваивае м ые образу нового процесса при выполнении операции порождения процесса (если в атрибуте spawn-flags установлен флаг POSIX_SPAWN_SETSCHEDULER или флаг POSIX_SPAWN_SETSCHEDPARAM). По у м олчанию значение этого атрибута не задано.

Возвращаемые значения

При успешном выполнении функция posix_spawnattr_getschedparam() возвращает нулевое значение и сохраняет значение атрибута spawn-schedparam из объекта атрибутов, адреcуемого пара м етро м attr, в объекте, адреcуемом параметро м schedparam, в противно м случае возвращается код ошибки, обозначающий ее характер.

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

Ошибки

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

[ EINVAL]  значение, заданное пара м етро м attr , недопусти м о.

Функция posix_spawnattr_setschedparam () м ожет завершиться неудачно, если:

[ EINVAL ]  устанавливае м ое значение атрибута недопусти м о.

Примеры

Отсутствуют.

Замечания по использованию

Эти функции являются частью опций Spawn и Process Scheduling и могут быть не представлены во всех реализациях.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

posix_spawn (), posix_spawnattr_destroy (), posix_spawnattr_init (), posix_spawnattr_getsigdefault(), posix_spawnattr_getflags(), posix_spawnattr_getpgroup(), posix_spawnattr_getschedpolicy(), posix_spawnattr_getsigmask(), posix_spawnattr_setsigdefault(), posix_spawnattr_setflags(), posix_spawnattr_setpgroup(), posix_spawnattr_setschedpolicy(), posix_spawnattr_setsigmask(), posix_spawnp (), том Base Definitions стан д арта IEEE Std 1003.1-2001, <sched.h>, <spawn.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 6, основанием послужил стандарт IEEE Std 1003.1d-1999.

Имя

posix_spawnattr_getschedpolicy, posix_spawnattr_setschedpolicy — функции считывания и установки атрибута spawn-schedpolicy из объекта атрибутов порожденного процесса (ADVANCED REALTIME).

Синопсис

SPN #include <spawn.h>

#include <sched.h>

int posix_spawnattr_getschedpolicy (const posix_spawnattr_t *restrict attr, int *restrict schedpolicy) ;

int posix_spawnattr_setschedpolicy (

posix_spawnattr_t *attr, int schedpolicy);

Описание

Функция posix_spawnattr_getschedpolicy() предназначена для получения значения атрибута spawn-schedpolicy из объекта атрибутов, адресуемого параметром attr.

Функция posix_spawnattr_setschedpolicy () позволяет установить атрибут spawn-schedpolicy в инициализированно м объекте атрибутов, адресуемом параметром attr.

Атрибут spawn-schedpolicy представляет стратегию планирования, назначаемую образу нового процесса при выполнении операции порождения процесса (если в атрибуте spawn-flags установлен флаг POSIX_SPAWN_SETSCHEDULER). П о умолчанию значение этого атрибута не задано.

Возвращаемые значения

П ри успешном выполнении функция posix_spawnattr_getschedpolicy () возвра щ ает нулевое значение и сохраняет значение атрибута spawn-schedpolicy из объекта атрибутов, адреcуемого параметром attr, в объекте, адреcуе м о м пара м етро м schedpolicy в противно м случае возвра щ ается код ошибки, обозначаю щ ий ее характер.

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

Ошибки

Выполнение этих функций м ожет завершиться неудачно, если: [ EINVAL ]  значение, заданное пара м етро м attr, недопустимо.

Функция posix_spawnattr_setschedpolicy () можетзавершиться неудачно, если: [ EINVAL ]  устанавливаемое значение атрибута недопустимо.

Пр и ложе ни е Б 535

Примеры

Отсутствуют.

Замечания по использованию

Эти функции являются частью опций Spawn и Process Scheduling и могут быть не пре д ставлены во всех реализациях.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

posix_spawn (), posix_spawnattr_destroy (), posix_spawnattr_init (), posix_spawnattr_getsigdefault(), posix_spawnattr_getflags(), posix_spawnattr_getpgroup (), posix_spawnattr_getschedparam(), posix_spawnattr_getsigmask (), posix_spawnattr_setsigdefault (), posix_spawnattr_setflags(), posix_spawnattr_setpgroup(), posix_spawnattr_setschedparam(), posix_spawnattr_setsigmask(), posix_spawnp (), том Base Definitions стандарта1ЕЕЕ Std 1003.1-2001, <sched.h>, <spawn.h>

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 6, основанием послужил стандарт IEEE Std 1003.1d-1999.

Имя

posix_spawnattr_getsigdefault, posix_spawnattr_setsigdefault —

функции считывания и установки атрибута spawn-sigdefault из объекта атрибутов порожденного процесса (ADVANCED REALTIME).

Синопсис

SPN

#include <signal.h>

#include <spawn.h>

int posix_spawnattr_getsigdefault (

const posix_spawnattr_t *restrict attr, sigset_t *restrict sigdefault);

int posix_spawnattr_setsigdefault (

posix_spawnattr_t *restrict attr, const sigset_t *restrict sigdefault);

Описание

Функция posix_spawnattr_getsigdefault() предназначена для получения значения атрибута spawn-sigdefault из объекта атрибутов, адресуе м ого параметром аttr.

Функция posix_spawnattr_setsigdefault() позволяет установить атрибут spawn-sigdefault в инициализированном объекте атрибутов, адресуемо м пара м етро м аttr.

Атрибут spawn-sigdefault представляет м ножество сигналов, которые должны быть подвергнуты обработке по у м олчанию в образе нового процесса (если в атрибуте spawn-flags установлен флаг POSIX_SPAWN_SETSIGDEF) при выполнении операции порождения процесса. По у м олчанию значение этого атрибута представляет собой пустое м ножество сигналов.

Возвращаемые значения

При успешно м выполнении функция posix_spawnattr_getsigdefault() возвра щ ает нулевое значение и сохраняет значение атрибута spawn-sigdefaul t из объекта атрибутов, адресуе м о г о пара м етро м attr, в объекте, адреcуемом пара м етро м sigdefault, в противном случае возвращается код ошибки, обоз н ачаю щ ий ее характер.

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

Ошибки

Выполнение этих функций м ожет завершиться неудачно, если: [EINVAL]  значение, заданное пара м етро м attr, недопусти м о.

Функция posix_spawnattr_setsigdefault () м ожет завершиться неудачно, если: [ EINVAL ]  устанавливае м ое значение атрибута недопусти м о.

Примеры

Отсутствуют.

Замечания по использованию

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

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

posix_spawn (), posix_spawnattr_destroy (), posix_spawnattr_init (), posix_spawnattr_getflags (), posix_spawnattr_getpgroup (), posix_spawnattr_getschedparam(), posix_spawnattr_getschedpolicy (), posix_spawnattr_getsigmask (), posix_spawnattr_setflags (), posix_spawnattr_setpgroup (), posix_spawnattr_setschedparam(), posix_spawnattr_setschedpolicy(), posix_spawnattr_setsigmask (), posix_spawnp (), том Base Definidons стандарта IEEE Std 1003.1-2001, <signal. h>, <spawn.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 6, основанием послужил стандарт IEEE Stdl003.1d-1999.

Имя

posix_spawnattr_getsigmask, posix_spawnattr_setsigmask— функции считывания и установки атрибута spawn-sigmask из объекта атрибутов порожденного процесса (ADVANCED REALTIME).

Синопсис

SPN #include <signal.h>

#include <spawn.h>

int posix_spawnattr_getsigmask (

const posix_spawnattr_t *restrict attr, sigset_t *restrict sigmask); int posix_spawnattr_setsigmask (

posix_spawnattr_t *restrict attr, const sigset_t *restrict sigmask);

Описание

Функция posix_spawnattr_getsigmask() предназначена для получения значения атрибута spawn-sigmask объекта атрибутов, адресуе м ого пара м етро м attr.

Функция posix_spawnattr_setsigmask() позволяет установить атрибут spawn-sigmask в инициализированном объекте атрибутов, адресуемом параметром attr .

Атрибут spawn-sigmask представляет м аску сигналов, предназначен н ую для использования в образе нового процесса при выполнении операции порождения процесса (если в атрибуте spawn-flags установлен флаг POSIX_SPAWN_SETSIGMASK). По у м олчанию значение этого атрибута не определено.

Возвращаемые значения

При успешно м выполнении функция posix_spawnattr_getsigmask() возвращает нулевое значение и сохраняет значение атрибута spawn-sigmask из объекта атрибутов, адресуе м ого пара м етро м attr, в объекте, адресуе м о м пара м етро м sigmask; в противно м случае возвращается код ошибки, обозначающий ее характер.

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

Ошибки

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

[EINVAL]   значение, заданное пара м етро м аttr, недопусти м о.

Функция posix_spawnattr_setsigmask () может завершиться неудачно, если:

[EINVAL ]  устанавливаемое значение атрибута недопустимо.

Примеры

Отсутствуют.

Замечания по использованию

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

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

posix_spawn (), posix_spawnattr_destroy (), posix_spawnattr_init (), posix_spawnattr_getsigdefault(), posix_spawnattr_getflags(), posix_spawnattr_getpgroup (), posix_spawnattr_getschedparam(), posix_spawnattr_getschedpolicy(), posix_spawnattr_setsigdefault(), posix_spawnattr_setflags (), posix_spawnattr_setpgroup (), posix_spawnattr_setschedparam(), posix_spawnattr_setschedpolicy(), posix_spawnp (), том Base Definitions стандарта IEEE Std 1003.1-2001, <signal. h>, <spawn.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 6, основанием послужил стандарт IEEEStd 1003.1d-1999.

Имя

pthread_attr_destroy, pthread_attr_init — функции разрушения и инициализации объекта атрибутов потока.

Синопсис

THR #include <pthread.h>

int pthread_attr_destroy (pthread_attr_t *attr); int pthread_attr_init (pthread_attr_t *attr);

Описание

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

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

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

Возвращаемые значения

При успешно м завершении эти функции возвращают нулевое значение; в противно м случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_attr_init () завершится неудачно, если:

[ENOMEM] для инициализации объекта атрибутов потока недостаточно существующей па м яти.

Эти функции не возвращают код ошибки в виде значения [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствует.

Логическое обоснование

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

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

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

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

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

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

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

1. Поддерживается стиль передачи функциям инициализации (pthread_create (), pthread_mutex_init (), pthread_cond_init ()) параметра, формируемого пу-тем применения поразрядной операции включающего ИЛИ к флагам. Содержащий эти флаги параметр (в расчете на расширяемость в булущем) должен иметь «непрозрачный» тип. Если в этом параметре флаги не установлены, то объекты создаются с использованием характеристик, действующих по умолчанию. Реализация самостоятельно может задавать значения флагов и соответствующее им поведение.

2. Если необходима дальнейшая специализация мьютексов и условных переменных, в реализациях могут быть определены дополнительные процедуры, предназначенные для выполнения действий над объектами типа pthread_mutex_t и pthread_cond_t (а не над объектами атрибутов).

При внедрении этого решения возможны следующие трудности.

1. Побитовая маска не будет считаться «закрытой», если биты должны быть установлены в векторных объектах атрибутов с использованием явно закодированных поразрядных операций включающего .ИЛИ. Если количество опций превышает размер типа int, прикладные программисты должны знать местоположение каждого бита. Если биты устанавливаются или считываются путем средств инкапсуляции (т.е. с помощью функций считывания и установки), то побитовал маска будет представлять собой всего лишь реализацию объектов атрибутов без свободного доступа для программиста.

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

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

Механизм атрибутов разработан по большей мере ради расширяемости. Будущие дополнения к механизму атрибутов или любому объекту атрибутов, определенному в этом томе (разделе) стандарта IEEE Std 1003.1-2001, необходимо вносить с чрезвычайной тщательностью, чтобы они не отразились на совместимости на уровне машинных кодов.

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

Будущие направления

Отсутствуют.

Смотри также

pthread_attr_getstackaddr(), pthread_attr_getstacksize(), pthread_attr_getdetachstate (), thread_create (), том Base Definidons стандарта IEEEStd 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширение м POSIX Threads Extension.

Issue 6

Функции pthread_attr_destroy() и pthread_attr_init() от м ечены как часть опции Threads.

При м еняется интерпретация IEEE PASC Interpretation 1003.1 #107, в которой указывается, что результат инициализации уже инициализированного объекта атрибутов потока не опре д елен.

Имя

pthread_attr_getdetachstate, pthread_attr__setdetachstate — функции считывания и записи атрибута detachstate.

Синопсис

THR #include <pthread.h>

int pthread_attr_getdetachstate (

const pthread_attr_t *attr, int *detachstate) ;

int pthread_attr_setdetachstate (pthread_attr_t *attr,

int detachstate) ;

Описание

Атрибут detachstate управляет тем, создается ли поток в открепленно м (отсоединенно м) состоянии. Если поток создается открепленным, то использование его идентификационного но м ера (ID) функция м и pthread_detach() или pthread_join () является ошибкой.

Функции pthread_attr_getdetachstate() и pthread_attr_setdetachstate() считывают и устанавливают соответственно атрибут detachstate в объекте атрибутов, адресуе м о м пара м етро м аttr.

С по м ощью функции pthread_attr_setdetachstate() приложение м ожет установить атрибут detachstate равны м либо значению PTHREAD_CREATE_DETACHED, либо значению PTHREAD_CREATE_JOINABLE.

С по м ощью функции pthread_attr_getdetachstate () считывается значение атрибута detachstate, которое м ожет быть равны м либо PTHREAD_ CREATE_DE TACHED, либо PTHREAD_CREATE_JO INABLE.

Значение PTHREAD_CREATE_DETACHED используется для перевода всех потоков, создавае м ых с по м ощью объекта, адресуе м ого пара м етро м attr, в открепленное состояние, в то вре м я как значение PTHREAD_CREATE_JO INABLE при м еняется для перевода всех потоков, создавае м ых с по м ощью объекта, адресуе м ого пара м етро м attr, в присоединенное состояние. По у м олчанию атрибут detachstate устанавливается равны м значению PTHREAD_CREATE_JO INABLE.

Возвращаемые значения

При успешно м завершении функции pthread_attr_getdetachstate () и pthread_attr_setdetachstate() возвращают нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Функция pthread_attr_getdetachstate() при успешно м выполнении сохраняет значение атрибута detachstate в пара м етре detachstate.

Ошибки

Функция pthread_attr_setdetachstate () завершится неу д ачно, если: [EINVAL ] значение, за д анное пара м етро м de tachsta te, недействительно. Эти функции не возвра щ ают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствует.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_attr_destroy (), pthread_attr_getstackaddr (),

pthread_attr_getstacksize (), pthread_create (), том Base Definidons стандарта IEEEStd 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширением POSIX Threads Extension.

Issue 6

Функции pthread_attr_getdetachstate() и pthread_attr_setdetachstate () от м ечены как часть опции Threads.

Раздел «Описание» был отредактирован с целью исключить из него слово «must» («должен»).

Имя

pthread_attr_getguardsize, pthread_attr_setguardsize— функции считывания и установки значения потоково г о атрибута guardsize.

Синопсис

XSI #include <pthread.h>

int pthread_attr_getguardsize (

const pthread_attr_t *restrict attr, size_t *restrict guardsize);

int pthread_attr_setguardsize (pthread_attr_t *attr,

size_t guardsize);

Описание

Функция pthread_attr_getguardsize () используется для считывания атрибута guardsize из объекта атрибутов, адресуе м ого пара м етро м attr. Этот атрибут возвращается в пара м етре guardsize.

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

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

Реализация может округлить значение, содержащееся в атрибуте guardsize, до числа, кратного значению реконфигурируемой системной переменной {PAGESIZE} (см. заголовок <sys/mman.h>). Если реализация округлит значение атрибута guardsize до числа, кратного значению пере м енной {PAGESIZE}, то при вызове функции pthread_attr_getguardsize () с заданным параметром attr в пара м етре guardsize сохранится размер защитной области, установленный в результате предварительного вызова функции pthread_attr_setguardsize ().

По у м олчанию значение атрибута guardsize равно {PAGESIZE} байтам. Реальное значение пере м енной {PAGESIZE} определяется реализацией.

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

Возвращаемые значения

При успешно м завершении функции pthread_attr_getguardsize() и pthread_attr_setguardsize() возвращают нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_attr_getguardsize () завершится неудачно, если:

[EINVAL ] значение, заданное пара м етро м guardsi ze, недействительно;

[ EINVAL ] значение пара м етра аttr недействительно.

Эти функции не возвращают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствует.

Логическое обоснование

Атрибут guardsize предла г ается для испо л ьзования при л ожение м по дву м причина м.

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

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

Будущие направления

Отсутствуют.

Смотри также

То м Base Definitions стандарта IEEE Std 1003.1-2001.

<pthread.h> , <sys/mman.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5.

Issue 6

Из раздела «Ошибки» было удалено третье условие возникновения ошибки [EINVAL] , поскольку оно включается во второе условие.

В целях согласования со стандарто м ISO/IEC 9899: 1999 в прототип функции pthread_attr_getguardsize () было добавлено ключевое слово restrict.

Имя

pthread_attr_getinheritsched, pthread_attr_setinheritsched— функции считывания и установки атрибута inheritsched (REALTIME THREADS).

Синопсис

THRTPS #include <pthread.h>

int pthread_attr_getinheritsched (

const pthread_attr_t *restrict attr, int *restrict inheritsched);

int pthread_attr_setinheritsched (pthread_attr_t *attr,

int inheritsched);

Описание

Функции pthread_attr_getinheritsched() и pthread_attr_setinheritsched() используются для считывания и установки соответственно атрибута inheri tsched в объекте, заданно м пара м етро м аttr.

Если при вызове функции pthread_create () используются объекты атрибутов, то атрибут inheritsched определяет, как будут устанавливаться другие атрибуты планирования создавае м ого потока.

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

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

Значения PTHREAD_INHERIT_SCHED и PTHREAD_EXPLICIT_SCHED определяются в заголовке <pthread. h>.

От значения атрибута inheritsched зависят следующие атрибуты планирования потоков, определенные стандарто м IEEE Std ЮОЗ.1-2001: стратегия планирования (schedpolicy), пара м етры планирования (schedparam) и область конкуренции (contentionscope).

Возвращаемые значения

При успешно м завершении функции pthread_attr_getinheritsched() Hpthread_attr_setinheritsched() возвращают нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_attr_setinheritsched () м ожет завершиться неудачно, если:

[EINVAL]  значение, заданное пара м етро м inheri tsched, недействительно;

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

Эти функции не возвра щ ают код ошибки [ EINTR].

Примеры

Отсутствуют.

Замечания по использованию

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

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_attr_destroy (), pthread_attr_getscope (), pthread_attr_getschedpolicy(), pthread_attr_getschedparam(), pthread_create (), то м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>, <sched.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширение м POSIX Threads Extension.

От м ечены как часть группы Realtime Threads Feature Group.

Issue 6

Функции pthread_attr_getinheritsched() и pthread_attr_setinheritsched () от м ечены как часть опций Threads и Thread Execution Scheduling.

Условие ошибки [ENOSYS] было удалено,поскольку в заглушках нет необходимости, если реализация не поддерживает опцию Thread Execution Scheduling.

В целях согласования со стандартом ISO/IEC 9899: 1999 в прототип функции pthread_attr_getinheritsched () было добавлено ключевое слово restrict.

Имя

pthread_attr_getschedparam, pthread_attr_setschedparam— функции считывания и установки атрибута schedparam.

Синопсис

THR #include <pthread.h>

int pthread_attr_getschedparam (const pthread_attr_t *restrict attr, struct sched_param *restrict param);

int pthread_attr_setschedparam (pthread_attr_t *restrict attr,const struct sched_param *restrict param);

Описание

Функции pthread_attr_getschedparam() и pthread_attr_setschedparam() используются для считывания и установки соответственно атрибутов параметров планирования в объекте, заданном параметром attr. Содержимое структуры param определено в заголовке <sched.h>. Для установки стратегий планирования SCHED_FIFO и SCHED_RR единственным обязательным членом структуры param является sched_priority.

TSP Для установки стратегии планирования SCHED_SPORADIC необходимо установить следующие члены структуры param: sched_priority, sched_ss_low_priority, sched_ss_repl_period, sched_ss_ini t_budget и sched_ss_max_repl. Для успешного выполнения функции установки необходи м о, чтобы заданное значение члена sched_ss_repl_period было больше или равно значению заданного члена sched_ss_init _ budget; в противно м случае функция завершится неудачно. Для успешного выполнения функции установки также необходи м о, чтобы значение члена sched_ss_max_repl находилось в пределах включающего диапазона [1.{SS_REPL_MAX}]; в противном случае функция завершится неудачно.

Возвращаемые значения

При успешном завершении функции pthread_attr_getschedparam() и pthread_attr_setschedparam() возвращают нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_attr_setschedparam () м ожет завершиться неудачно, если:

[EINVAL]  значение, заданное пара м етро м param, недействительно;

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

Эти функции не возвращают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

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

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_attr_destroy(), pthread_attr_getscope(), pthread_attr_getinheritsched(), pthread_attr_getschedpolicy(), pthread_create (), то м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>, <sched.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширение м POSIX Threads Extension.

Отмечены как часть группы Realtime Threads Feature Group.

Issue 6

Функции pthread_attr_getschedparam () и pthread_attr_setschedparam () отмечены как часть опции Threads.

В целях согласования со стандарто м IEEE Std 1003.1d-1999 была добавлена стратегия планирования SCHED_SPORADIC.

В целях согласования со стандарто м ISO/IEC 9899: 1999 в прототипы функций pthread_attr_getschedparam() и pthread_attr_setschedparam() было добавлено ключевое слово restrict.

Имя

pthread_attr_getschedpolicy, pthread_attr_setschedpolicy — функции считывания и установки атрибута schedpolicy (REALTIME THREADS).

Синопсис

THR, TPS

#include <pthread.h>

int pthread_attr_getschedpolicy (const pthread_attr_t *restrict attr, int *restrict policy) ;

int pthread_attr_setschedpolicy (pthread_attr_t *attr, int policy) ;

Описание

Функции pthread_attr_getschedpolicy () и pthread_attr_setschedpolicy () используются для считывания и установки соответственно атрибута schedpolicy в объекте атрибутов, адресуемом параметром аttr.

Для обозначения стратегии планирования поддерживаются значения SCHED_FIF0, SCHED_RR и SCHED_OTHER, которые определены в заголовке <sched. h>.

TSP Когда потоки, выполняющиеся с использованием стратегий планирования SCHED_FIFO, SCHED_RR или SCHED_SPORADIC, ожидают освобождения мьютекса, то его получение (после разблокировки) происходит согласно приоритета м.

Возвращаемые значения

При успешном завершении функции pthread_attr_getschedpolicy() и pthread_attr_setschedpolicy() возвращают нулевое значение; в противно м случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_attr_setschedpolicy () м ожет завершиться неудачно, если:

[EINVAL] значение, заданное пара м етро м policy, недействительно;

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

Эти функции не возвращают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

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

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_attr_destroy(), pthread_attr_getscope(), pthread_attr_getinheritsched (), pthread_attr_getschedparam(), pthread_create (), том Base Definidons стан д арта IEEE Std 1003.1-2001, <pthread.h>, <sched.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширение м POSIX Threads Extension.

От м ечены как часть группы Realtime Threads Feature Group.

Issue 6

Функции pthread_attr_getschedpolicy() и pthread_attr_setschedpolicy () от м ечены как часть опций Threads и Thread Execution Scheduling.

Условие ошибки [ENOSYS] было удалено, поскольку в заглушках нет необходимости, если реализация не поддерживает опцию Thread Execution Scheduling.

В целях согласования со стандарто м IEEE Std 1003.1d-1999 была добавлена стратегия планирования SCHED_SPORADIC.

В целях согласования со стандарто м ISO/IEC 9899: 1999 в прототип функции pthread_attr_getschedpolicy () было добавлено ключевое слово restrict.

Имя

pthread_cancel — функция от м ены выполнения потока.

Синопсис

THR #include <pthread.h>

int pthread_cancel (pthread_t thread);

Описание

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

Действия, связанные с от м еной заданного потока, выполняются асинхронно по отношению к потоку, вызывающему функцию pthread_cancel ().

Возвращаемое значение

При успешном завершении функция pthread_cancel () возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_cancel () м ожет завершиться неудачно, если:

[ESRCH] не удалось найти поток, иде н тификационный но м ер (ID) которого соответствовал бы заданно м у.

Функция pthread_cancel () не возвра щ ает код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Для отправки потоку уведо м ления об от м ене расс м атривалось два альтернативных варианта. Для одного предполагалось определить новый сигнал SIGCANCEL с соответствующей семантикой отмены, а для другого— новую функцию pthread_cancel (), которая бы приводила в действие процедуру отмены потока.

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

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

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

Будущие направления

Отсутствуют.

Смотри также

pthread_exit (), pthread_cond_timedwait (), pthread_join (), pthread_setcancelstate (), то м Base D e finitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функция впервые реализована в выпуске Issue 5. Включена для согласования с расширение м POSIX Threads Ext e nsion.

Issue 6

Функция pthread_cancel () от м ечена как часть опции Thr e ads.

Имя

pthread_cleanup_pop, pthread_cleanup_push— функции создания обработчиков запроса об от м ене потоков.

Синопсис

THR

#include <pthread.h>

void pthread_cleanup_pop (int execute);

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

Описание

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

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

• поток существует (т.е. он вызывает функцию pthread_exit ());

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

• поток вызывает функцию pthread_cleanup_pop() с ненулевым значением аргумента execute.

Эти функции можно реализовать как макросы. Приложение должно гарантировать, что они имеют форму инструкций и используются попарно в пределах одного и того же лексического контекста (чтобы макрос pthread_cleanup_push () раскрывался в список лексем, начинающийся лексемой '{', а макрос pthread_cleanup_pop() раскрывался в список лексем, завершающийся соответствующей лексемой '}').

Результат вызова функции longjmp() или siglongjmp() не определен, ec-ли имели место обращения к функции pthread_cleanup_push() или pthread_cleanup_pop() без соответствующего «парного» вызова по причине заполнения буфера переходов. Результат вызова функции longjmp () или siglongjmp() из обработчика, предназначенного для выполнения подготовительных действий по аннулированию потока, также не определен.

Возвращаемые значения

Функции pthread_cleanup_push() и hread_cleanup_pop() не возвра щ ают никакого значения.

Ошибки

Ошибки не определены.

Эти функции не возвращают код ошибки [EINTR].

Примеры

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

typedef struct {

pthread_mutex_t lock; pthread_cond_t rcond, wcond;

int lock_count;

/* lock_count < 0 .. Удерживается записывающим потоком. */ /* lock_count > 0 .. Удерживается lock_count считывающими * потоками. */

/* lock_count = 0 .. Ничем не удерживается. */ int waiting_writers; /* Счетчик ожидающих записывающих

* потоков. */

} rwlock;

void

waiting_reader_cleanup (void, *arg) {

rwlock *1;

1 = (rwlock *) arg;

pthread_mutex_unlock (&l->lock);

}

void

lock_for_read (rwlock *1) {

pthread_mutex_lock (&l->lock);

pthread_cleanup_push (waiting_reader_cleanup, 1) ;

while ((l->lock_count < 0) && (l->waiting_writers ! = 0))

pthread_cond_wait (&l->rcond, &l->lock);

l->lock_count++;

/*

* Обратите внимание на то, что функция pthread_cleanup_pop()

* выполняет здесь фyнкциюwaiting_reader_cleanup(). */

pthread_cleanup_pop(l); }

void

release_read_lock (rwlock *1) {

pthread_mutex_lock (&l->lock); if (--l->lock_count == 0) pthread_cond_signal (&l->wcond); pthread_mutex_unlock (1);

void

waiting_writer_cleanup (void *arg) {

rwlock *1;

1 = (rwlock *) arg;

if ((—l->waiting_writers == О) && (l->lock_count >= 0)) { /*

* Это происходит только в случае отмены потока. */

pthread_cond_broadcast (&l->wcond);

}

pthread_mutex_unlock (&l->lock);

}

void

lock_for_write (rwlock *1) {

pthread_mutex_lock (&l->lock),-l->waiting_writers++;

pthread_cleanup_push (waiting_writer_cleanup, 1); while (l->lock_count ! = О) pthread_cond_wait (&l->wcond, &l->lock); l->lock_count = -1; /*

* Обратите внимание на то, что функция pthread_cleanup_pop()

* выполняет здесь функцию waiting_writer_cleanup(). */

pthread_cleanup_pop (1);

}

void

release_write_lock (rwlock *1) {

pthread_mutex_lock (&l->lock);

l->lock_count = 0;

if (l->waiting_writers == О)

pthread_cond_broadcast (&l->rcond)

else

pthread_cond_signal (&l->wcond); pthread_mutex_unlock (&l->lock);

}

/*

* Эта функция вызывается для инициализации блокировки

* чтения-записи. */

void

initialize_rwlock (rwlock *1) {

pthread_mutex_init (&l->lock, pthread_mutexattr_default); pthread_cond_init (&l->wcond, pthread_condattr_default); pthread_cond_init (&l->rcond, pthread_condattr_default); l->lock_count = О; l->waiting_writers = О;

\

Приложение Б 559

}

reader_thread() {

lock_for_read (&lock);

pthread_cleanup_push (release_read_lock, &lock); /*

* Поток устанавливает блокировку для чтения. */

pthread_cleanup_pop (1);

}

writer_thread() {

lock_for_write (&lock);

pthread_cleanup_push (release_write_lock, &lock); /*

* Поток устанавливает блокировку для записи. */

pthread_cleanup_pop (1) ;

}

Замечания по использованию

Две описываемые здесь функции, pthread_cleanup_push() и pthread_cleanup_pop (), которые помещают и извлекают из стека обработчики запроса на отмену потока, можно сравнить с левой и правой круглыми скобками. Их нужно всегда использовать «в паре».

Логическое обоснование

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

#define pthread_cleanup_push (rtn, arg) { \

struct _pthread_handler_rec _cleanup_handler, **_head; \

_cleanup_handler.rtn = rtn; \

_cleanup_handler.arg = arg; \

(void) pthread_getspecific (_pthread_handler_key, &_head);

\

_cleanup_handler.next = *_head; \

*_head = &_cleanup_handler;

#define pthread_cleanup_pop (ex) \

*_head = _cleanup_handler.next; \

if (ex) (*_cleanup_handler.rtn) (_cleanup_handler.arg); \

}

Возможна даже более «смелая» реализация этих функций, которая позволит компилятору «считать» обработчик запроса на отмену константой, значение которой можно «встраивать» в код. В данном томе стандарта IEEE Std 1003.1-2001 пока оставлен неопределенным результат вызова функции longjmp () из обработчика сигнала, выполняемого в функции библиотеки POSIX System Interfaces. Если в какой-то реализации потребуется разрешить этот вызов и придать ему надлежащее поведение, функция longjmp () должна в этом случае вызвать все обработчики запроса на отмену, которые были помещены в стек (но еще не извлечены из него) с момента вызова функции setjmp ().

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

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

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

Будущие направления

Отсутствуют.

Смотри также

pthread_cancel(), pthread_setcancelstate(), то м Base Definitions стандарта IEEEStd ЮОЗ.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширение м POSIX Threads Extension.

Issue 6

Функции pthread_cleanup_pop() и pthread_cleanup_push() от м ечены как часть опции Threads.

Добавлен раздел «За м ечания по использованию» (APPLICATION USAGE).

Раздел «Описание» был отредактирован с целью исключить из него слово « must» («должен»).

Имя

pthread_cond_broadcast(),pthread_cond_signal()

Описание

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

Функция pthread_cond_broadcast () позволяет разблокировать все потоки, заблокированные в данный момент с использованием переменной условия, заданной параметром cond.

Функция pthread_cond_signal () используется для разблокировки по крайней мере одного из потоков, заблокированных с использованием условной переменной, заданной параметром cond (если таковые существуют). Если с использованием этой переменной условия заблокировано несколько потоков, то порядок разблокировки будет определен в соответствии с их стратегией планирования. Когда каждый поток, разблокированный в результате вызова функции pthread_cond_broadcast () или pthread_cond_signal(), вернется из вызванной им функции pthread_cond_wait () или pthread_cond_timedwait(), этот поток получит мьютекс, с которым была вызвана функция pthread_cond_wait() или pthread_cond_timedwait(). Разблокированные потоки будут состязаться за мьютекс в соответствии с их стратегией планирования (если это имеет смысл), как будто каждый из них вызвал функцию pthread_mutex_lock ().

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

Функции pthread_cond_broadcast() и pthread_cond_signal() не будут иметь результата, если в данный момент не су щ ествует потоков, заблокированных с использованием условной переменной, за д анной параметром cond.

Возвращаемые значения

При успешном завершении функции pthread_cond_broadcast () и pthread_ cond_signal () возвра щ ают нулевое значение; в противном случае — ко д ошибки, обозначаю щ ий ее характер.

pthread_cond_broadcast, pthread_cond_signal — функции разблокировки потоков, заблокированных с по м о щ ью пере м енной условия.

Синопсис

THR

#include <pthread.h>

int pthread_cond_broadcast (pthread_cond_t *cond);

int pthread_cond_signal (pthread_cond_t *cond);

|Ошибки

Функции pthread_cond_broadcast () и pthread_cond_signal () м огут завершиться неудачно, если:

[EINVALJ значение, заданное параметром cond, не ссылается на инициализированную условную переменную.

Эти функции не возвращают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

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

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

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

Логическое обоснование

Несколько запусков по условному сигналу

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

pthread_cond_wait(mutex, cond):

value = cond->value; /* 1 */

pthread_mutex_unlock (mutex); /* 2 */

pthread_mutex_lock (cond->mutex); /* 10 */

if (value == cond->value) { /* 11 */

me->next_cond = cond->waiter;

cond->waiter = me;

pthread_mutex_unlock(cond->mutex);

unable_to_run (me);

} else

pthread_mutex_unlock (cond->mutex); /* 12 */

pthread_mutex_lock (mutex); /* 13 * /

pthread_cond_signal (cond):

pthread_mutex_lock (cond->mutex); /* 3 */

cond->value++; /* 4 */

if (cond->waiter) { /* 5 */

sleeper = cond->waiter; /* 6 */

cond->waiter = sleeper->next_cond; /* 7 */

able_to_run (sleeper); /* 8 */

}

pthread_mutex_unlock (cond->mutex); /* 9 */

Итак, в результате одного обращения к функции pthread_cond_signal () сразу несколько потоков могут вернуться из вызова функции pthread_cond_wait () или pthread_cond_timedwait (). Такой эффект называется «фиктивным запуском». Обратите внимание на то, что подобная ситуация является самокорректирующейся благодаря тому, что количество потоков, «пробуждающихся» таким путем, ограничено; например, следующий поток, который вызывает функцию pthread_cond_wait (), после определенной последовательности событий блокируется.

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

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

Будущие направления

Отсутствуют.

Смотри также

pthread_cond_destroy (), pthread_cond_timedwait (), том Base Definitions cтaндapтa IEEEStd 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширение м POSIX Threads Extension.

Issue 6

Функции pthread_cond_broadcast() и pthread_cond_signal() от м ечены как часть опции Threads.

Добавлен раздел «Замечания по использованию» (APPLICATION USAGE).

Имя

pthread_cond_destroy, pthread_cond_init

Синопсис

THR

#include <pthread.h>

int pthread_cond_destroy (pthread_cond_t *cond);

int pthread_cond_init (

pthread_cond_t *restrict cond,

const pthread_condattr_t *restrict attr);

pthread_cond_t cond = PTHREAD_COND_INITIALIZER;

Описание

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

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

Функция pthread_cond_init() используется для инициализации условной пере м енной, адресуе м ой пара м етро м cond, объекто м атрибутов, адресуе м ы м пара м етро м attr. Если пара м етр attr со д ержит значение NULL, для инициализации применяются атрибуты условной переменной, действующие по умолчанию, т.е. результат в этом случае равносилен передаче адреса объекта, содержащего стандартные атрибуты условной пере м енной. После успешной инициализации Условная Переменная становится инициализированной.

Для осуществления синхронизации используется только сама условная переменная cond. Результат ссылки на копии пере м енной cond в обращениях к функциям pthread_cond_wait(), pthread_cond_timedwait(), pthread_cond_signal(), pthread_cond_broadcast() и pthread_cond_destroy() неопределен. Попытка инициализировать уже инициализированную условную переменную приведет к неопределенному поведению.

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

Возвращаемые значения

При успешно м завершении функции pthread_cond_destroy() и pthread_cond_init() возвращают нулевое значение; в противно м случае— код ошибки, обозначающий ее характер.

Проверка на наличие ошибок с кодами [EBUSY] и [EINVAL] реализована так (если реализована вообще), как будто она выполняется в самом начале работы каждой функции, и код ошибки в случае ее обнаружения возвращается до модификации состояния условной переменной, заданной параметром cond.

Ошибки

Функция pthread_cond_destroy () может завершиться неудачно, если:

[EBUSY] реализация обнаружила попытку разрушить объект, адресуемый параметром cond, который относится к другому потоку (например, при использовании в функциях pthread_cond_wait() или pthread_cond_timedwait ());

[EINVAL] значение, заданное пара м етро м cond, недействительно.

Функция pthread_cond_init () завершится неудачно, если:

[EAGAIN] система испытывает недостаток в ресурсах (не имеется в виду память), необходимых для инициализации еще одной условной переменной;

[ENOMEM] для инициализации условной переменной недостаточно существующей памяти.

Функция pthread_cond_init () может завершиться неудачно, если:

[EBUSY] реализация обнаружила попытку повторно инициализировать объект условной переменной, адресуемый параметром cond, которой был ранее инициализирован, но еще не разрушен;

[ EINVAL ] значение, заданное параметром аttr, недействительно.

Примеры

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

struct list {

pthread_mutex_t lm;

}

struct elt {

key k;

int busy;

pthread_cond_t notbusy;

}

/* Находим элемент списка и сохраняем его. */

struct elt * list_find (struct list *lp, key k) {

struct elt *ep;

pthread_mutex_lock (&lp->lm);

while ((ep = find_elt (1, к) ! = NULL) && ep->busy)

pthread_cond_wait (&ep->notbusy, &lp->lm);

if (ер != NULL) ep->busy = 1;

pthread_mutex_unlock (&lp->lm) ;

return (ер);

}

delete_elt (struct list *lp, struct elt *ep) {

pthread_mutex_lock (&lp->lm);

assert (ep->busy);

//... удаляем элемент ер из списка …

ep->busy = 0; /* Paranoid. */

(A) pthread_cond_broadcast (&ep->notbusy);

pthread_mutex_unlock (&lp->lm);

(B) pthread_cond_destroy (&rp->notbusy);

free (ер);

}

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

Замечания по использованию

Отсутствуют.

Логическое обоснование

С м. раздел «Логическое обоснование» в описании функции pthread_mutex_init ().

Будущие направления

Отсутствуют.

Смотри также

pthread_cond_broadcast (), pthread_cond_signal (), pthread_cond_timedwait (), то м Base Definidons стандартаШЕЕStd 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширение м POSIX Threads Extension.

Issue 6

Функции pthread_cond_destroy() и pthread_cond_init() от м ече н ы как часть опции Threads.

Раздел «Описание» был отредактирован путе м при м енения интерпретации IEEE PASC Interpretation 1003.1с #34.

В целях согласования со стандарто м ISO/IEC 9899:1999 в прототип функции pthread_cond_init () было добавлено ключевое слово restrict.

Имя

pthread_cond_timedwait, pthread_cond_wait — функции ожидания условия.

Синопсис

THR

#include <pthread.h>

int pthread_cond_timedwait ( pthread_cond_t *restrict cond, pthread_mutex_t *restrict mutex, const struct timespec *restrict abstime);

int pthread_cond_wait (pthread_cond_t *restrict cond, pthread_mutex_t *restrict mutex);

Описание

Функции pthread_cond_timedwait() и pthread_cond_wait() используются для блокирования потоков по условной переменной. Они вызываются с использованием мьютекса mutex , блокируемого вызывающим потоком; в противном случае результирующее поведение не определено.

Эти функции автоматически освобождают мьютекс mutex и обеспечивают блокирование вызывающего потока по условной переменной cond; «автоматически» здесь означает «автоматический доступ к мьютексу со стороны другого потока с последующим доступом к условной переменной». Другими словами, если какой-то другой поток может получить мьютекс после его освобождения вызывающим потоком, то результат последующего вызова функции pthread_cond_broadcast () или pthread_cond_signal () в этом (другом) потоке будет таким, как если бы он имел место после блокирования вызывающего потока.

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

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

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

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

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

Функция pthread_cond_timedwait() эквивалентна функции pthread_cond_wait (), за исключением того, что она возвращает код ошибки, если абсолютное время, заданное пара м етро м abstime, наступит (т.е. системное время станет равным или превысит значение abstime) до того, как будет передано (с помощью сигнала) условие cond, или если абсолютное время, заданное параметром abstime, уже наступило в момент вызова.

C S Если поддерживается опция Clock Selection, условная переменная будет иметь атрибут часов, определяющий механизм, который предназначен для измерения времени, заданного параметром abstime . По истечении заданного времени функция pthread_cond_timedwait() освободит и снова захватит мьютекс, адресуемый параметром mutex . Функция pthread_cond_timedwait () также представляет собой точку отмены.

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

Возвращаемые значения

За исключением кода ошибки [ETIMEDOUT], все проверки на наличие ошибок реализованы так, как если бы они были выполнены в самом начале работы каждой функции, и код ошибки в случае ее обнаружения возвращается до модификации состояния мьютекса, заданного пара м етро м mutex, или условной переменной, заданной параметром cond.

При успешном завершении возвращается нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_cond_timedwait () завершится неудачно, если:

[ETIMEDOUT]  вре м я, заданное пара м етро м abstime, наступило.

Функции pthread_cond_timedwait() и pthread_cond_wait() м огут завершиться неудачно, если:

[EINVAL] значение, заданное хотя бы одни м из пара м етров cond, mutex или abstime, недействительно;

[EINVAL] для выполнения параллельных операций pthread_cond_timedwait() или pthread_cond_wait () по одной и той же условной пере м енной были задействованы различные мьютексы;

[EPERM]  во вре м я вызова любой из функций мьютексом не владел текущий поток.

Эти функции не возвращают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Семантика ожидания по условию

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

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

В общем случае при каждом завершении ожидания по условию поток должен оценивать значение предиката, связанного с ожиданием по условию, чтобы узнать, может ли он безопасно продолжать выполнение, ожидать или объявить тайм-аут. Возврат из состояния ожидания не означает, что соответствующий предикат имеет конкретное значение (ЛОЖЬ или ИСТИНА).

Поэтому рекомендуется ожидание по условию выражать в коде, эквивалентно м циклу «while», который выполняет проверку предиката.

Семантика ожидания по времени

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

clock_gettime(CLOCK_REALTIME, &now)

reltime = sleep_til_this_absolute_time -now;

cond_relative_timed_wait (с, m, &reltime);

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

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

Аннулирование потока и ожидание по условию

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

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

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

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

Быстродействие мьютексов и условных переменных

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

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

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

Особенности мьютексов и условных переменных

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

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

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

Синхронизированное ожидание по условию

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

(void) pthread_mutex_lock (&t. mn);

t.waiters++;

clock_gettime (CLOCK_REALTIME, &ts) ;

ts.tv_sec += 5;

rc = 0;

while (! mypredicate (&t) && rc == 0)

rc = pthread_cond_timedwait (&t.cond, &t.mn, &ts);

t.waiters--;

if (rc == 0) setmystate (&t);

(void) pthread_mutex_unlock (&t.mn);

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

Будущие направления

Отсутствуют.

Смотри также

pthread_cond_signal (), pthread_cond_broadcast (), том Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширением POSIX Threads Extension.

Issue 6

Функции pthread_cond_timedwait() и pthread_cond_wait() от м ечены как часть опции Threads.

К описанию прототипа функции pthread_cond_wait () был приложен список опечаток Open Group Corrigendum U021/9.

Для согласования со стандартом IEEE Std 1003.1j-2000 раздел «Описание» был отредактирован путем добавления семантики для опции Clock Selection.

В раздел «Ошибки» внесен еще один код ошибки [EPERM] в ответ на включение интерпретации IEEE PASC Interpretation 1003.1с #28.

В целях согласования со стандартом ISO/IEC 9899: 1999 в прототипы функций pthread_cond_timedwait() и pthread_cond_wait() было добавлено ключевое слово restrict.

Имя

pthread_condattr_destroy, pthread_condattr_init — функции разрушения и инициализации объекта атрибутов условной пере м енной.

Синопсис

THR

#include <pthread.h>

int pthread_condattr_destroy (pthread_condattr_t *attr);

int pthread_condattr_init (pthread_condattr_t *attr);

Описание

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

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

Если функция pthread_condattr_init () вызывается для уже инициализированного объекта атрибутов attr , то результаты вызова этой функции не определены.

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

Этот то м стан д арта IEEE Std 1003.1-2001 требует наличия д вух атрибутов: clock и process-shared.

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

Возвращаемые значения

При успешно м завершении функции pthread_condattr_destroy() Hpthread_condattr_init() возвращают нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_condattr_destroy () может завершиться неудачно, если:

[EINVAL]  значение, заданное параметром аttr, недействительно.

Функция pthread_condattr_init () завершится неудачно, если:

[ENOMEM]  для инициализации объекта атрибутов условной переменной недостаточно существующей памяти. Эти функции не возвращают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

С м. описание функций pthread_attr_init () и pthread_mutex_init (). Атрибут process-shared был определен для условных переменных по той же причине, что и для м ьютексов.

Будущие направления

Отсутствуют.

Смотри также

pthread_attr_destroy (), pthread_cond_destroy (), pthread_condattr_getpshared(), pthread_create(),

pthread_mutex_destroy (), то м Base Definitions стан д арта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширение м POSIX Threads Extension.

Issue 6

Функции pthread_condattr_destroy() и pthread_condattr_init() от м ечены как часть опции Threads.

Имя

pthread_condattr_getpshared, pthread_condattr_setpshared — функции считывания и установки атрибутаусловной пере м енной process-shared.

Синопсис

THR TSH

#include <pthread.h>

int pthread_condattr_getpshared (const pthread_condattr_t *restrict attr, int *restrict pshared);

int pthread_condattr_setpshared (pthread_conda 11 r_t * аttr, int pshared) ;

Описание

Функция pthread_condattr_getpshared () используется для получения значения атрибута process - shared из объекта атрибутов, адресуе м ого параметром attr. Функция pthread_condattr_setpshared() позволяет установить атрибут process-shared в инициализированно м объекте атрибутов, адресуе м о м пара м етро м attr .

Атрибут process-shared устанавливается равным значению PTHREAD_PROCESS_ SHARED, чтобы разрешить использование условной переменной любым потоком, имеющим доступ к области памяти, в которой она размещена, даже если эта область памяти разделяется несколькими процессами. Если же атрибут process-shared равен значению PTHREAD_PROCESS_PRIVATE , Условная Переменная должна использоваться только потоками, созданными в одном процессе с потоком, который ее инициализировал; если с этой условной переменной попытаются работать потоки из различных процессов, поведение такой программы не определено. По умолчанию для этого атрибута устанавливается значение PTHREAD_PROCESS_PRIVATE.

Возвращаемые значения

При успешном завершении функция pthread_condattr_setpshared() возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

При успешном завершении функция pthread_condattr_getpshared() возвращает нулевое значение и сохраняет считанное значение атрибута process-shared объекта attr в объекте, адресуемом параметром pshared; в противном случае возвращается код ошибки, обозначающий ее характер.

Ошибки

Функции pthread_condattr_getpshared () и pthread_condattr_setpshared () м огут завершиться неудачно, если:

[EINVAL]  значение, заданное пара м етром attr , недействительно.

Функция pthread_condattr_setpshared () м ожет завершиться неудачно, если:

[EINVAL]  новое значение, заданное для атрибута, не попадает в диапазон значений, действительных для этого атрибута. Эти функции не возвращают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_create (), pthread_cond_destroy (), pthread_condattr_destroy (), pthread_mutex_destroy (), то м Base Definidons стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширение м POSIX Threads Extension.

Issue 6

Функции pthread_condattr_getpshared () и pthread_condattr_setpshared () от м ечены как часть опций Threads и Thread Process-Shared Synchronization.

В целях согласования со стандартом ISO/IEC 9899: 1999 в прототип функции pthread_condattr_getpshared () было добавлено ключевое слово restrict.

Имя

pthread_create — функция создания потока.

Синопсис

THR

#include <pthread.h>

int pthread_create (pthread_t *restrict thread, const pthread_attr_t *restrict attr, void * (*start_routine) (void*), void *restrict arg);

Описание

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

При создании потока выполняется функция start_routine, которая вызывается с единственным аргументом arg . Если функция start_routine выполнится до конца, то результат будет таким, как если бы было сделано явное обращение к функции pthread_exit (), использующей в качестве состояния выхода (exit status) значение, возвращаемое функцией start_routine. Обратите внимание на то, что поток, в котором изначально вызывалась функция main(), отличается от функции start_routine. При выходе из функции main () результат будет таким, как если бы было сделано явное обращение к функции exit (), использующей в качестве состояния выхода значение, возвращаемое функцией main ().

Статус сигналов для нового потока будет инициализирован следующим образом:

• маска сигналов будет унаследована от создающего потока;

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

Среда обработки данных с плавающей точкой будет унаследована от создающего потока.

При неудачном выполнении функции pthread_create () поток не создается, а содержимое области, адресуемое параметром thread, остается неопределенным.

TCT

 Если определено значение _POSIX_THREAD_CPUTIME, новый поток получит доступ к таймеру центрального процессора (CPU-time clock), и начальное значение для этих часов будет установлено равным нулю.

Возвращаемое значение

При успешном завершении функция pthread_create () возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_create () завершится неудачно, если:

[EAGAIN] в системе недостаточно ресурсов, необходимых для создания еще одного потока, или был превышен предел ({PTHREAD_THREADS_MAX}), установленный в системе для общего количества потоков в процессе;

[EINVAL] значение, заданное параметром attr , недействительно;

[EPERM] инициатор вызова не имеет соответствующего разрешения на установку требуемых параметров планирования или стратегии планирования.

Эта функция не возвращает код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

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

Разбиение этой операции на две части разработчиками стандарта было отклонено по нескольким причинам.

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

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

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

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

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

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

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

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

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

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

• Эффективность снизилась бы, поскольку пришлось бы копировать по крайней мере некоторую часть стека, несмотря на то, что в большинстве случаев после вызова нужной «запускающей» функции потоку уже не требуется скопированный контекст.

Будущие направления

Отсутствуют.

Смотри также

fork (), pthread_exit () , pthread_join (), то м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функция впервые реализована в выпуске Issue 5. Включена для согласования с расширением POSIX Threads Extension.

Issue 6

Функция pthread_create () от м ечена как часть опции Threads.

В результате согласования со спецификацией Single UNIX Specification был добавлен обязательный код ошибки [EPERM].

С целью согласования со ста н дарто м IEEE Std 1003.1d-1999 для потока была добавлена се м антика тай м ера центрального процессора.

Для согласования со стандарто м ISO/IEC 9899: 1999 в прототип функции pthread_create () было добавлено ключевое слово restrict.

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

Имя

pthread_detach — функция отсоединения потока.

Синопсис

THR

#include <pthread.h>

int pthread_detach (pthread_t thread);

Описание

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

Возвращаемое значение

При успешном завершении функция pthread_detach () возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_detach () завершится неудачно, если:

[EINVAL] реализация обнаружила, что значение, заданное параметром thread, не относится к присоединенному потоку;

[ESRCH] не был найден ни один поток, соответствующий заданному идентификационному номеру потока ID.

Эта функция не возвращает код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

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

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

1. В обработчике запроса на отмену для функции присоединения потока (pthread__join()) важно иметь функцию pthread_detach(), чтобы отсоединить поток. Без нее обработчик вынужден был бы выполнить еще раз функцию pthread_j oin (), чтобы попытаться отсоединить поток, который не только задерживает процедуру отмены в течение неограниченного времени, но и вносит новый вызов функции pthread_join(). В этом случае есть смысл говорить о динамическом отсоединении.

2. Чтобы отсоединить «исходный поток» (это может понадобиться в процессах, которые создают потоки сервера).

Будущие направления

Отсутствуют.

Смотри также

pthread_join (), том Base Definitions стандарта IEEE Std 1003.1-2001, <pthread. h>.

Последовательность внесения изменений

Функция впервые реализована в выпуске Issue 5. Включена д ля согласования с расширение м POSIX Threads Extension.

Issue 6

Функция pthread_detach () отмечена как часть опции Threads.

Имя

pthread_exit — функция завершения потока.

Синопсис

THR #include <pthread.h>

void pthread_exit (void *va2ue_ptr);

Описание

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

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

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

После завершения потока результат доступа к локальным переменным потока не определен. Таким образом, ссылки на локальные переменные существующего потока не следует использовать для функции pthread_exit () в качестве значения параметра value_ptr.

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

Возвращаемое значение

Функция pthread_exit () не возвращается к инициатору ее вызова.

Ошибки

Ошибки не определены.

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

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

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

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

Будущие направления

Отсутствуют.

Смотри также

exit (), pthread_create (), pthread_join (), том Base Definitions стан д арта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функция впервые реализована в выпуске Issue 5. Включена для со г ласования с расширение м POSIX Threads Extension.

Issue 6

Функция pthread_exit () от м ече н а как часть опции Threads.

Имя

pthread_getconcurrency, pthread_setconcurrency — функции считывания и установки уровня параллелизма.

Синопсис

XSI

 #include <pthread.h>

int pthread_getconcurrency (void);

int pthread_setconcurrency (int new_level);

Описание

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

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

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

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

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

Возвращаемые значения

При успешном выполнении функция pthread_setconcurrency() возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Функция pthread_getconcurrency () всегда возвращает уровень параллелизма, установленный в результате предыдущего обращения к функции pthread_setconcurrency (). Если «предыдущего» вызова этой функции не было, функция pthread_getconcurrency () возвращает нуль.

Ошибки

Фу н кци я pthread_setconcurrency () завершится неудачно, если:

[EINVAL ] значение, заданное пара м етро м new_level , отрицательно;

[EAGAIN] значение, заданное пара м етро м new_level, приводит к перерасхолу систе м ных ресурсов.

Эти функции не возвращают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Использование этих функций изменяет состояние базового уровня параллелизма, от которого зависит работа приложения. Разработчикам библиотек рекомендуется не использовать функции pthread_getconcurrency() и pthread_setconcurrency(), поскольку это может привести к конфликту с их использованием в приложении.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

То м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5.

Имя

pthread_getschedparam, pthread_setschedparam — функции динамического доступа к параметрам стратегии планирования потока (REALTIME THREADS).

Синопсис

THR TPS

#include <pthread.h>

int pthread_getschedparam (pthread_t thread, int *restrict policy, struct sched_param *restrict param);

int pthread_setschedparam (pthread_t thread, int policy, const struct sched_param *param);

Описание

Функции pthread_getschedparam() и pthread_setschedparam() используются для считывания и установки соответственно значений стратегии планирования и параметров отдельных потоков многопоточного процесса. Для значений стратегии планирования SCHED_FIFO и SCHED_RR в структуре sched_param должен быть установлен только один ее член sched_priority [27] (уровень приоритета). Для значения SCHED_OTHER параметры планирования определяются реализацией.

Функция pthread_getschedparam() пре д назначена для считывания значения стратегии пла н ирования и пара м етров планирования для потока, идентификационный но м ер (ID) которого задан пара м етро м thread. Считанные значения сохраняются в пара м етрах policy и param. Функция pthread_getschedparam() возвра щ ает значение приоритета, установленное в результате са м ого последнего вызова функций pthread_setschedparam(), pthread_setschedprio() или pthread_create () для данного потока. Она не отражает никаких временных корректировок, вносимых в значение приоритета в результате выполнения других функций. Функция pthread_setschedparam() устанавливает для потока, ID которого за д ан пара м етро м thread, стратегию планирования и соответствую щ ие пара м етры планирования равны м и значения м пара м етров policy и nparam соответственно.

Параметр роlicy м ожет и м еть значения SCHED_OTHER, SCHED_FIFO или SCHED_RR. Параметры планирования для стратегии планирования, заданной значением SCHED_OTHER, определяются реализацией. Для страте г ии планирования, задавае м ой значения м и SCHED_FIFO и SCHED_RR, используется только один пара м етр priority.

TSP

Если определено значение _POSIX_THREAD_SPORADIC_SERVER, аргу м ент роlicy может иметь значение SCHED_SPORADIC (за исключение м функции pthread_setschedparam()). Если стратегия планирования в момент вызова этой функции не соответствовала значению SCHED_SPORADIC, то поддержка этого значения определяется реализацией, т.е. реализация может не позволить приложению динамически изменять стратегию планирования, устанавливая ee равной значению SCHED_SPORADIC. Для стратегии планирования, определяе м ой значение м SCHED_SPORADIC, устанавливаются такие пара м етры: sched_ss_low_priority, sched_ss_repl_period, sched_ss_init_budget, sched_priority и sched_ss_max_repl. Для успешного выполнения фу н кции установки пара м етров значение пара м етра sched_ss_repl_period должно быть больше или равно значению sched_ss_init_budget; в противном случае функция завершится неудачно. Кро м е того, для успешного выполнения этой функции значение пара м етра sched_ss_max_repl должно попадать во включающий диапазон [1, SS_REPL_MAX] ; в противном случае функция завершится неудачно.

При неудачном завершении функции pthread_setschedparam() параметры планирования для заданного потока изменены не будут.

Возвращаемые значения

П ри успешно м завершении функции pthread_getschedparam() Hpthread_setschedparam() возвра щ ают нулевое значение; в противно м случае — кодошибки, обозначаю щ ий ее характер.

Ошибки

Функци я pthread_getschedparam () м ожет завершитьс я неудачно, если:

[ESRCH]  з н ачение, заданное пара м етро м thread, не относится ни к од-

ному из существующих потоков.

Функция pthread_setschedparam() может завершиться неудачно, если:

[EINVAL]  значение, заданное параметром policy, или значение одного из параметров планирования, связанных со значением стратегии планирования policy, недействительно;

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

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

инициатор вызова не имеет соответствующего разрешения устанавливать параметры планирования или стратегию планирования для заданного потока;

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

значение, заданное пара м етро м thread, не относится ни к одному из существующих потоков.

Эти функции не возвращают код ошибки [EINTR].

[ENOTSUP]

TSP [ENOTSUP]

[EPERM]

[EPERM]

[ESRCH]

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_setschedprio (), sched_getparam(), sched_getscheduler (), то м Base Definitions craHjapTaIEEEStd 1003.1-2001, <pthread.h>, <sched.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширением POSIX Threads Extension.

Issue 6

Функции pthread_getschedparam() и pthread_setschedparam() от м ечены как часть опций Threads и Thread Execution Scheduling.

Код ошибки [ENOSYS] был исключен, поскольку е г о нет с м ысла учитывать, если реализация не под д ерживает опцию Thread Execution Scheduling.

К описанию прототипа функции pthread_setschedparam() был приложен список опечаток Open Group Corrigendum U026/2, чтобы второй ар г у м ент этой функции и м ел тип int.

Для согласования со стандартом IEEE Std 1003.1d-1999 было добавлено значение стратегии планирования SCHED_SPORADIC.

В целях согласования со стандартом ISO/IEC 9899: 1999 в прототип функции pthread_getschedparam () было добавлено ключевое слово restrict.

Был добавлен список опечаток Open Group Corrigendum U047/1.

Быладобавлена интерпретация IEEE PASC 1тегрге1а1юп 1003.1 #96, отмечающая» что значения приоритета также можно установить путем вызова функции pthread_setschedprio().

Имя

pthread_join — функция ожидания завершения потока.

Синопсис

THR

#include <pthread.h>

int pthread_join (pthread_t thread, void **value _ptr);

Описание

Функция pthread_join() приостанавливает выполнение вызывающего потока до тех пор, пока не завершится заданный поток (если он еще не завершился). Если после удачного возвращения из функции pthread_join () параметр value_ptr не равен значению NULL значение, передавае м ое функции pthread_exit() завершающимся потоком, будет доступным в области памяти, адресуемой параметром value_ptr. Успешное выполнение функции pthread_join () означает, что заданный поток завершился. Результаты нескольких одновременных обращений к функции pthread_join (), в параметрах которых задается один и тот же поток, не определены. Если поток, вызывающий функцию pthread_join(), отменен, то заданный поток не будет выгружен.

Не определено, учитывается ли в значении {PTHREAD_THREADS_MAX} поток, который завершился, но остался отсоединенным.

Возвращаемые значения

При успешном завершении функция pthread_join () возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_join () завершится неудачно, если:

[EINVAL]  реализация обнаружила, что значение, заданное параметром thread, не относится ни к одному из присоединенных потоков;

[ESRCH]  не найден ни один поток, идентификационный номер которого (ID) соответствовал бы заданному потоку.

Функция pthread_join () может завершиться неудачно, если:

[EDEADLK]  была обнаружена взаимоблокировка или значение параметра thread соответствует вызывающему потоку.

Функция pthread_join () не возвращает код ошибки [EINTR].

Примеры

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

typedef struct {

int *ar;

long n;

} subarray;

void *incer (void *arg) {

long i;

for (i = О; i < ((subarray *)arg) ->n; i++) ((subarray *) arg) ->ar[i]++;

}

int main (void) {

int ar[1000000];

pthread_t th1, th2;

subarray sbl, sb2;

sbl.ar = &ar[О];

sbl.n = 500000;

(void) pthread_create(&thl, NULL, incer, &sbl);

sb2.ar = &ar[500000];

sb2.n = 500000;

(void) pthread_create(&th2, NULL, incer, &sb2);

(void) pthread_join(thl, NULL);

(void) pthread_join(th2, NULL);

return 0;

}

Замечания по использованию

Отсутствуют.

Логическое обоснование

Функция pthread_join() представляет собой удобное и полезное средство для использования в многопоточных приложениях. Конечно, программист мог бы сымитировать эту функцию, если бы она не существовала, другими средствами, например, путем передачи функции start_routine () дополнительного состояния как части аргумента. Завершающийся поток в этом случае установил бы флаг, означающий завершение, и отправил бы условную переменную, которая является частью этого состояния, а присоединяющий поток ожидал бы получения этой условной переменной. Несмотря на то что такой метод позволил бы организовать ожидание наступления более сложных условий (например, завершения сразу нескольких потоков), ожидание завершения одного потока— весьма распространенная ситуация, и поэтому «заслуживает» отдельной функции. Кроме того, включение в библиотеку функции pthread_join () никоим образом не мешает программисту самому кодировать такие сложные ожидания. Таким образом, включение функции pthread_join () в этот том стандарта IEEE Std 1003.1-2001 считается весьма полезным.

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

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

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

Взаимодействие между функцией pthread_join () и механизмом отмены потока хорошо определено по следующим причинам:

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

• отмена потока не может происходить в состоянии запрещения отмены.

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

Будущие направления

Отсутствуют.

Смотри также

pthread_create(), wait(), том Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функция впервые реализована в выпуске Issue 5. Включена для согласования с расширение м POSIX Threads Extension.

Issue 6

Функция pthread_join () отмечена как часть опции Threads.

Имя

pthread_mutex_destroy, pthread_mutex_init — функции разруше н ия и инициализации мьютекса.

Синопсис

THR

#include <pthread.h>

int pthread_mutex_destroy (pthread_mutex_t *^utex);

int pthread_mutex_init (

pthread_mutex_t *restrict jnutex,

const pthread_mutexattr_t *restrict attr);

pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;

Описание

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

Нет никакой опасности в разрушении инициализированного объекта мьютекса, по которому не заблокирован в данный момент ни один поток. Попытка же разрушить заблокированный мьютекс может привести к неопределенно м у поведению.

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

Для осуществления синхронизации используется только сам объект, адресуемый параметром mutex. Результат ссылки на копии объекта mutex в обращениях к функциям pthread_mutex_lock(), pthread_mutex_trylock(), pthread_mutex_unlock() и pthread_mutex_destroy () не определен.

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

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

Возвращаемые значения

При успешном завершении функции pthread_mutex_destroy() и pthread_ mutex_init () возвращают нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Проверка на наличие ошибок с кодами [EBUSY] и [EINVAL] реализована так (если реализована вообще), как будто она выполняется в самом начале работы каждой функции, и код ошибки в случае ее обнаружения возвращается до модификации состояния мьютекса, заданного параметром mutex.

Ошибки

Функция pthread_mutex_destroy () может завершиться неудачно, если:

[EBUSY]  реализация обнаружила попытку разрушить объект, адресуе м ый параметром mutex, который относится к другому потоку (напри м ер, при использовании в функциях pthread_mutex_wait () или pthread_mutex_timedwait ()), или указанный объект заблокирован;

[EINVAL] значение, заданное пара м етро м mutex, недействительно.

Функция pthread_mutex_init () завершится неудачно, если:

[EAGAIN] система испытывает недостаток ресурсов (не имеется в виду память), необходимых для инициализации еще одного мьютекса;

[ENOMEM] для инициализации мьютекса недостаточно существующей памяти;

[EPERM]  инициатор вызова функции не имеет привилегий для выполнения этой операции.

Функция pthread_mutex_init () м ожет завершиться неудачно, если:

[EBUSY]  реализация обнаружила попытку повторно инициализировать объект мьютекса, адресуемый параметром mutex, которой был ранее инициализирован, но еще не разрушен;

[EINVAL ] значение, заданное пара м етро м attr, недействительно. Эти функции не возвра щ ают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Возможность альтернативных реализаций

Данный том стандарта IEEE Std 1003.1-2001 поддерживает несколько альтернативных реализаций мьютексов. Реализация может сохранять блокировку непосредственно в объекте типа pthread_mutex_t. Возможно также хранение блокировки в «куче», а указателя, дескриптора или уникального ID — в объекте мьютекса. Каждая реализация обладает различными достоинствами в зависимости от определенных конфигураций оборудования. Поэтому, чтобы написать код, который не нужно будет изменять в зависимости от выбранной реализации, в данном томе стандарта IEEE Std 1003.1-2001 жестко не определяется тип хранения блокировки и термин «инициализировать» используется для усиления утверждения о том, что блокировка может в действительности располагаться в самом объекте мьютекса.

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

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

Компромисс между контролем за ошибками и производительностью

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

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

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

Почему не определяются предельные значения

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

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

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

Без применения статической инициализации функция самоинициализации foo () может иметь следующий вид.

static pthread_once_t foo_once = PTHREAD_ONCE_INIT;

static pthread_mutex_t foo_mutex;

void foo_init () {

pthread_mutex_init (&foo_mutex, NULL);

}

void foo() {

pthread_once(&foo_once, foo_init);

pthread_mutex_lock (&foo_mutex);

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

pthread_mutex_unlock (&foo_mutex);

}

С применением статической инициализации ту же функцию самоинициализации foo() м ожно было бы закодировать таки м образо м.

static pthread_mutex_t foo_mutex = PTHREAD_MUTEX_INITIALIZER;

void foo()

{

pthread_mutex_lock(&foo_mutex) ;

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

pthread_mutex_unlock(&foo_mutex);

}

Обратите внимание на то, что статическая инициализация устраняет необходимость в тестировании, проводимом в функции pthread_once (), и получении значения адреса &foo_mutex, передаваемого функции pthread_mutex_lock() или pthread_mutex_unlock ().

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

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

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

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

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

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

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

Разрушение мьютексов

Мьютекс можно разрушить сразу после разблокировки. Например, рассмотрим следующий код.

struct obj {

pthread_mutex_t om;

int refcnt;

};

obj_done (struct obj *op) {

pthread_mutex_lock (&op- >om);

if (—op- >refcnt == 0) {

pthread_mutex_unlock (&op- >om);

(A) pthread_mutex_destroy (&op- >om);

(B) free(op); } else

(С) pthread_mutex_unlock (&op->om);

}

В данном случае структура obj служит для учета количества ссылок, а функция obj_done() вызывается всякий раз, когда удаляется ссылка на объект. Реализации должны позволить разрушение объекта и освобождение занимаемых им ресурсов (см. строки А и В) сразу после его разблокировки (строка С).

Будущие направления

Отсутствуют.

Смотри также

pthread_mutex_getprioceiling (), pthread_mutex_lock (), pthread_mutex_timedlock (), pthread_mutexattr_getpshared (), том Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширение м POSIX Threads Extension.

Issue 6

Функции pthread_mutex_destroy() и pthread_mutex_init() от м ечены как часть опции Threads.

В целях согласования со стандарто м IEEE Std 1003.1d-1999 в раздел «С м отри также» была добавлена функция pthread_mutex_timedlock ().

Раздел «Описание» б ы л отредактирован путе м при м енения интерпретации IEEE PASC Interpretation 1003.1с #34.

В целях согласования со стандартом ISO/IEC 9899: 1999 в прототип функции pthread_mutex_init () было добавлено ключевое слово restrict.

Имя

THR TPP

pthread_mutex_getprioceiling, pthread_mutex_setprioceiling — функции считывания и установки предельного значения приоритета мьютекса (REALTIME THREADS).

Синопсис

#include <pthread.h>

int pthread_mutex_getprioceiling (

const pthread_mutex_t *restrict mutex, int *restrict prioceiling) ; int pthread_mutex_setprioceiling (

pthread_mutex_t *restrict mutex, int prioceiling, int *restrict old_ceiling) ;

Описание

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

При неудачном выполнении функции pthread_mutex_setprioceiling() предельное значение приоритета мьютекса не будет изменено.

Возвращаемые значения

При успешном завершении функции pthread_mutex_getprioceiling() и pthread_mutex_setprioceiling() возвращают нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функции pthread_mutex_getprioceiling () и pthread_mutex_setprioceiling () могут завершиться неудачно, если:

[EINVAL]  приоритет, заданный пара м етро м prioceiling, не попадает в нужный диапазон:

[EINVAL]  значение, заданное пара м етро м mutex, не относится ни к одно м у из существующих мьютексов;

[ EPERM]  инициатор вызова не и м еет привиле г ий д л я выпо л нения этой операции.

Эти функции не возвра щ ают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_mutex_destroy(),pthread_mutex_lock(),

pthread_mutex_timedlock (), то м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширением POSIX Threads Extension.

Отмечены как часть группы Realtime Threads Feature Group.

Issue 6

Функции pthread_mutex_getprioceiling () и pthread_mutex_setprioceiling () отмечены как часть опций Threads и Thread Execution Scheduling.

Код ошибки [ENOSYS] был исключен, поскольку его нет смысла учитывать, если реализация не поддерживает опцию Thread Priority Protection.

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

В целях согласования со стандартом IEEE Std 1003.1d-1999 в раздел «Смотри также была добавлена функция pthread_mutex_timedlock ().

В целях согласования со стандартом ISO/IEC 9899: 1999 в прототипы функции pthread_mutex_getprioceiling() и pthread_mutex_setprioceiling() было добавлено ключевое слово restrict.

Имя

pthread_mutex_lock, pthread_mutex_trylock, pthread_mutex_unlock — функции блокировки и разблокировки мьютекса.

Синопсис

THR #include <pthread.h>

int pthread_mutex_lock (pthread_mutex_t *.mutex) ; int pthread_mutex_trylock (pthread_mutex_t *mutex); int pthread_mutex_unlock (pthread_mutex_t *mutex);

Описание

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

XSI  Ес л и м ьютекс и м еет тип PTHREAD_MUTEX_NORMAL , обнаружение взаимоблокировок не обеспечивается. К взаимоблокировке может привести попытка заблокировать мьютекс повторно. Если поток попытается разблокировать мьютекс, который не заблокирован, дальнейшее ero поведение не определено.

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

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

Если м ьютекс и м еет тип PTHREAD_MUTEX_DEFAULT, попытка рекурсивно заблокировать мьютекс приводит к неопределенному поведению. Попытка разблокировать мьютекс, который не был заблокирован (любым потоком, включал вызывающий), приводит к неопределенному поведению.

Функция pthread_mutex_trylock () эквивалентна функции

pthread_mutex_lock (), за исключением того, что если объект мьютекса, адресуемый параметром mutex, в данный момент заблокирован (любым потоком, включал текущий), эта функция немедленно завершится. Если мьютекс имеет тип PTHREAD_MUTEX_RECURSIVE , и в данный момент мьютексом владеет вызывающий поток, счетчик блокировок этого мьютекса инкрементируется, а функция pthread_mutex_trylock () немедленно возвращает признак успешного завершения.

Функция pthread_mutex_unlock () освобождает объект м ьютекса, адресуе м ый пара м етро м mutex.

XSI  Способ освобождения зависит от атрибута типа м ьютекса.

Если при вызове функции pthread_mutex_unlock (), в результате которого мьютекс стал доступным, существуют потоки, заблокированные по объекту мьютекса, адресуемому параметром мьютекс, то поток-владелец этого мьютекса будет установлен стратегией планирования. XSI  

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

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

Возвращаемые значения

При успешном завершении функции pthread_mutex_lock() npthread_mutex_unlock() возвращают нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Функция pthread_mutex_trylock () возвращает нулевое значение, если выполнена блокировка по объекту мьютекса, адресуемому параметром mutex. В противном случае возвращается код ошибки, обозначающий ее характер.

Ошибки

Функции pthread_mutex_lock () и pthread_mutex_trylock () завершатся неудачно, если:

[EINVAL] мьютекс был создан с использованием атрибута protocol, имеющего значение PTHREAD_PRIO_PROTECT, а приоритет вызывающего потока выше текущего значения предельного приоритета мьютекса.

Функция pthread_mutex_trylock () завершится неудачно, если:

[EBUSY] мьютекс остался недоступным, поскольку он был уже заблокирован.

Функции pthread_mutex_lock() , pthread_mutex_trylock()

и pthread_mutex_unlock () м огут завершиться неудачно, если:

[EINVAL] значение, заданное пара м етро м mutex, не относится к инициализированно м у объекту м ьютекса;

XSI [EAGAIN] мьютекс остался недоступным, поскольку было превышено максимальное количество рекурсивных блокировок для мью-текса, заданного параметром mutex.

Функция pthread_mutex_lock () м ожет завершиться неудачно, ес л и:

[ EDEADLK ]  текущий поток уже владеет мьютексом.

Функция pthread_mutex_unlock () м ожет завершиться неудачно, ес л и:

[ EPERM ]  текущий поток не владеет мьютексом.

Эти функции не возвра щ ают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

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

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

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

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

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

Будущие направления

Отсутствуют.

Смотри также

pthread_mutex_destroy (), pthread_mutex_timedlock (), то м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования c расширением POSIX Threads Extension.

Issue 6

Функции pthread_mutex_lock (), pthread_mutex_trylock () и pthread_mutex_ unlock () отмечены как часть опции Threads.

В результате согласования со спецификацией Single UNIX Specification было определено поведение при попытке повторно заблокировать мьютекс.

В целях согласования со стандартом IEEE Std 1003.1d-1999 в раздел «Смотри также» была добавлена функция pthread_mutex_timedlock ().

Пр и ложе ни е Б 607

Имя

pthread_mutex_timedlock — функция блокировки мьютекса (ADVANCED REALTIME).

Синопсис

THR

#include <pthread.h>

TMO

#include <time.h>

int pthread_mutex_timedlock ( pthread_mutex_t *restrict mutex, const struct timespec *restrict abs_timeout);

Описание

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

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

TMR Если поддерживается опция Timers, отсчет интервала вре м ени проис ходит с использованием часов CLOCK_REALTIME; в противном случае — с использованием системных часов, значение которых возвращает функция time ().

Разрешение для интервала времени определяется разрешением часов, которые используются для его отсчета. Тип данных timespec определяется в заголовке <time. h>.

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

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

Возвращаемое значение

При успешном завершении функция pthread_mutex_timedlock() возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_mutex_timedlock () завершится неудачно, если:

[EINVALJ  мьютекс был создан с использованием атрибута protocol, и м еющего значение PTHREAD_PRIO_PROTECT, а приоритет вызывающего потока выше текущего значения предельного приоритета м ьютекса;

[EINVAL]  процесс или поток заблокирован, а пара м етр abs_timeout в поле наносекунд и м еет значение, которое м еньше нуля либо больше или равно 1000 млн;

[ETIMEDOUT] мьютекс не удалось заблокировать до истечения заданного интервала времени.

Функция pthread_mutex_timedlock () может завершиться неудачно, если:

[EINVAL] значение, заданное пара м етро м mutex, не относится к инициализированному объекту мьютекса; XSI [EAGAIN] мьютекс остался недоступным, поскольку было превышено максимальное количество рекурсивных блокировок для мьютекса, заданного параметром mutex

[ EDEADLK] текущий поток уже владеет мьютексом.

Эта функция не возвращает код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

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

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_mutex_destroy (), pthread_mutex_lock(), pthread_mutex_trylock(), time (), то м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread. h>, <time. h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 6, основанием послужил стандарт IEEEStd 1003.1d-1999.

Имя

pthread_mutexattr_destroy

Синопсис

THR #include <pthread.h>

int pthread_mutexattr_destroy (

pthread_mutexattr_t *attr); int pthread_mutexattr_init (pthread_mutexattr_t *attr);

Описание

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

Результаты не определены, если функция pthread_mutexattr_init () вызывается, ссылаясь на уже инициализированный объект атрибутов attr.

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

Возвращаемые значения

При успешно м завершении функции pthread_mutexattr_destroy() и pthread_mutexattr_init () возвра щ ают нулевое значение; в противно м случае — код ошибки, обозначаю щ ий ее характер.

Ошибки

Функция pthread_mutexattr_destroy () м ожет завершиться неудачно, если:

[EINVAL ]  значение, заданное параметром attr, недействительно.

Функция pthread_mutexattr_init () завершится неудачно, если:

[ENOMEM]  для инициализации объекта атрибутов м ьютекса недостаточно существующей памяти.

Эти функции не возвра щ ают код ошибки [EINTR].

pthread_mutexattr_destroy, pthread_mutexattr_init — функции разрушения и инициализации объекта атрибутов м ьютекса.

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

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

Рассматривалась возможность использования таких дополнительных атрибутов мьютексов, как spin__only, limited spin, no__spin, recursive и metered. (Считаем необходимым разъяснить назначение таких атрибутов, как recursive nmetered: рекурсивные мьютексы позволяют выполнение нескольких повторных блокировок со стороны текущего владельца; мьютексы с регистрирацией фиксируют длину очереди, время ожидания и т.д.) Поскольку еще нет достаточных данных о том, насколько полезны эти атрибуты, в данном томе стандарта IEEE Std 1003.1-2001 они не определены. Однако объекты атрибутов мьютексов позволяют проверить эти идеи на предмет возможной их стандартизации в будущем.

Атрибуты мьютекса и производительность

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

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

Использование общей памяти и синхронизация процессов

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

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

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

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

/* sem.h */

struct semaphore {

pthread_mutex_t lock;

pthread_cond_t nonzero;

unsigned count;

};

typedef struct semaphore semaphore_t;

semaphore_t *semaphore_create (char *semaphore_name);

semaphore_t *semaphore_open (char *semaphore_name);

void semaphore_post (semaphore_t *semap);

void semaphore_wait (semaphore_t *semap); void semaphore_close (semaphore_t *semap);

/* sem.c */

#include <sys/types.h> #include <sys/stat.h> #include <sys/mman.h> #include <fcntl.h> #include <pthread.h> #include 11 sem .h»

semaphore_t *

semaphore_create (char * semaphore_name) t

int fd;

semaphore_t * semap; pthread_mutexattr_t psharedm;

pthread_condattr_t psharedc;

fd = open(semaphore_name, O_RDWR | O_CREAT | O_EXCL, Оббб); if (fd <0)

return (NULL); (void) ftruncate (fd, sizeof (semaphore_t)); (void) pthread_mutexattr_init (&psharedm); (void) pthread_mutexattr_setpshared(&psharedm,

PTHREAD_PROCESS_SHARED) ;

(void) pthread_condattr_init (&psharedc); (void) pthread_condattr_setpshared (&psharedc

PTHREAD_PROCESS_SHARED);

semap = (semaphore_t *) mmap (NULL, sizeof (semaphore_t),

PR0T_READ | PROT_WRITE, MAP_SHARED, fd, О);

close (fd);

(void) pthread_mutex_init (&semap->lock, &psharedm);

(void) pthread_cond_init (&semap->nonzero, &psharedc); semap->count = 0; return (semap);

}

semaphore_t *

semaphore_open (char *semaphore_name) {

int fd;

semaphore_t *semap;

fd = open (semaphore_name, O_RDWR, 0666); if (fd <0)

return (NULL);

semap = (semaphore_t *) mmap (NULL, sizeof (semaphore_t),

PROT_READ | PROT_WRITE, MAP_SHARED, f d, 0) ;

close (fd); return (semap);

}

void

semaphore_post (semaphore_t *semap) {

pthread_mutex_lock (&semap->lock); if (semap->count == 0)

pthread_cond_signal (&semapx->nonzero); semap->count++;

pthread_mutex_unlock (&semap->lock);

}

void

semaphore_wait (semaphore_t * semap) {

pthread_mutex_lock (&semap->lock); while (semap->count == 0)

pthread_cond_wait (&semap->nonzero, &semap->lock); semap->count--;

pthread_mutex_unlock (&semap->lock);

}

void

semaphore_close (semaphore_t *semap) {

munmap ((void *) semap, sizeof (semaphore_t));

}

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

/* create.c */

# include «pthread. h»

#include «sem.h»

int main() {

semaphore_t * semap;

semap = semaphore_create («/ tmp/semaphore») ; if (semap == NULL)

exit(l); semaphore_close (semap) ,-return (0);

}

/* post */

# include «pthread. h»

#include «sem.h»

int main() {

semaphore_t *semap;

semap = semaphore_open ("/tmp/semaphore»);

if (semap == NULL)

exit (1);

semaphore_post (semap);

semaphore_close (semap);

return (0);

}

/* wait */

#include «pthread.h»

#include «sem.h» int

main () {

semaphore_t *semap;

semap = semaphore_open ("/tmp/semaphore ¹¹ ); if (semap == NULL)

exit (1); semaphore_wait (semap); semaphore_close (semap); return (0);

}

Будущие направления

Отсутствуют.

Смотри также

pthread_cond_destroy (), pthread_create (), pthread_mutex_destroy (), pthread_mutexattr_destroy (), том Base Definitions стандарта IEEE Std 1003.1-2001,<pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширением POSIX Threads Extension.

Issue 6

Функции pthread_mutexattr_destroy() и pthread_mutexattr_init () отмечены как часть опции Threads.

Раздел «Ошибки» был отредактирован путем при м енения интерпретации IEEE PASC Interpretation 1003.1с #27.

Имя

pthread_mutexattr_getprioceiling, pthread_mutexattr_setprioceiling

Синопсис

THR #include <pthread.h> TPP

int pthread_mutexattr_getprioceiling (

const pthread_mutexattr_t *restrict attr, int *restrict prioceiling); int pthread_mutexattr_setprioceiling (

pthread_mutexattr_t *attr, int prioceiling);

Описание

Функции pthread_mutexattr_getprioceiling() и pthread_mute-xattr_setprioceiling () используются для считывания и установки соответственно атрибута prioceiling в объекте атрибутов м ьютекса, адресуе м о г о параметром attr, который был ранее создан с помо щ ью функции pthread_mutexattr_init ().

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

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

Возвращаемые значения

При успешно м завершении функции pthread_mutexattr_getprioceiling() и pthread_mutexattr_setprioceiling() возвращают нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функции pthread_mutexattr_getprioceiling () и pthread_mutexattr_setprioceiling () могут завершиться неудачно, если:

[EINVAL] значение, заданное пара м етро м attr, или пара м етро м prioceiling, недействительно;

[EPERM] инициатор вызова не обладает привеле г ия м и для выполнения этой операции.

Эти функции не возвра щ ают код ошибки [EINTR].

pthread_mutexattr_getprioceiling, pthread_mutexattr_setprioceiling — функции считывания и установки атрибута prioceiling в объекте агрибутов м ьютекса (REALTIME THREADS).

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_cond_destroy(), pthread_create(), pthread_mutex_destroy(), том Base Definitions стандарта1ЕЕЕ Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для со г ласования с расширением POSIX Threads Extension.

Отмечены как часть группы Realtime Threads Feature Group.

Issue 6

Функции pthread_mutexattr_getprioceiling() и pthread_mutexattr_setp-rioceiling () отмечены как часть опций Threads и Thread Priority Protection.

Код ошибки [ENOSYS] был исключен, поскольку его нет смысла учитывать, если реализация не под д ерживает опцию Thread Priority Protection.

Ко д ошибки [ENOTSUP] был исключен, поскольку эти функции не имеют аргумента protocol.

В целях согласования со стан д артом ISO/IEC 9899: 1999 в прототип функции pthread_mutexattr_getprioceiling() было д обавлено ключевое слово restrict.

Имя

pthread_mutexattr_setprotocol, pthread_mutexattr_getprotocol

Синопсис

THR #include <pthread.h>

TPP|TPI

int pthread_mutexattr_getprotocol (const pthread_mutexattr_t *restrict attr, int *restrict protocol);

int pthread_mutexattr_setprotocol (

pthread_mutexattr_t * attr, int protocol) ;

Описание

Функции pthread_mutexattr_getprotocol() и pthread_mutexattr_setprotocol () используются для считывания и установки соответственно атрибута protocol в объекте атрибутов м ьютекса, адресуе м о г о пара м етро м attr, который был ранее создан с помощью функции pthread_mutexattr_init ().

Параметр protocol определяет протокол, которому необходимо следовать при использовании мьютексов. Этот атрибут может иметь следующие значения (которые определены в заголовке <pthread. h>):

PTHREAD_PRIO_NONE

TPI  PTHREAD_PRIO_INHERIT

TPP  PTHREAD_PRIO_PROTECT

Если поток владеет мьютексом с использованием значения PTHREAD_PRIO_NONE для атрибута protocol, то факт обладания мьютексом не отражается на значении его приоритета и стратегии планирования.

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

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

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

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

TPI Если поток обращается к функции pthread_mutex_lock (), а атрибут protocol задавае м ого м ьютекса был инициализирован значение м PTHREAD_PRIO_INHERIT, и если вызывающий поток блокируется из-за того, что м ьютекс прина д лежит друго м у потоку, то этот поток — владелец м ьютекса — наследует уровень приоритета вызываю щ его потока, приче м до тех пор, пока он продолжает удерживать м ьютекс. Реализация устанавливает приоритет выполнения согласно м акси м ально м у значению (выбранного из заданного и всех унаследованных приоритетов). Более того, если этот поток — владелец м ьютекса са м блокируется по друго м у м ьютексу, такой же эффект наследования приоритетов рекурсивно распространяется и на этого владельца.

Возвращаемые значения

При успешно м завершении функции pthread_mutexattr_getprotocol() и pthread_mutexattr_setprotocol () возвра щ ают нулевое значение; в противно м случае — код ошибки, обозначаю щ ий ее характер.

Ошибки

Функция pthread_mutexattr_setprotocol () завершится неудачно, если:

[ ENOTSUP ] значение, заданное пара м етро м pro tocol , не по д держивается.

Функции pthread_mutexattr_getprotocol() и pthread_mutexattr_setprotocol () м огут завершиться неу д ачно, если:

[EINVAL] значение, заданное пара м етро м attr, или пара м етро м protocol, недействительно;

[EPERM] инициатор вызова не обладает привиле г ия м и для выполнения этой операции.

Эти функции не возвра щ ают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_cond_destroy (), pthread_create (), pthread_mutex_destroy (), то м Base Defmidons стандартаШЕЕ Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширением POSIX Threads Extension.

Отмечены как часть группы Realtime Threads Feature Group.

Issue 6

Функции pthread_mutexattr_getprotocol() и pthread_mutexattr_setprotocol () от м ечены как часть опции Threads и одной из опций Thread Priority Protection или Thread Priority Inheritance.

Код ошибки [ENOSYS] был исключен, поскольку его нет с м ысла учитывать, если реализация не по д держивает опции Thread Priority Protection или Thread Priority Inheritance.

В целях согласования со стан д арто м ISO/IEC 9899:1999 в прототип функции pthread_mutexattr_getprotocol () было д обавлено ключевое слово restrict.

Имя

pthread_mutexattr_getpshared, pthread_mutexattr_setpshared — функ-ции считывания и установки атрибута process-shared.

Синопсис

THR #include <pthread.h> TSH

int pthread_mutexattr_getpshared (

const pthread_mutexattr_t *restrict attr, int *restrict pshared); int pthread_mutexattr_setpshared(

pthread_mutexattr_t *attr, int pshared);

Описание

Функция pthread_mutexattr_getpshared () используется дл я получения значения атрибута process - shared объекта атрибутов, адресуе м о г о пара м етро м attr. Функция pthread_mutexattr_setpshared() позволяет установить атрибут process-shared в инициализированно м объекте атрибутов, адресуе м о м пара м етро м attr.

Атрибут process-shared устанавливается равны м значению PTHREAD_PROCESS_SHARED, чтобы позволить обработку м ьютекса любы м дру г и м потоко м, который и м еет доступ к па м яти, в которой раз м е щ ен этот м ьютекс, даже если он раз м е щ ен в па м яти, сов м естно используе м ой нескольки м и процесса м и. Если атрибут process-shared установлен равны м значению PTHREAD_PROCESS_PRIVATE, м ьютекс будет обрабатываться только теми потоками, созданными в одном процессе с потоком, который инициализировал этот мьютекс; если потоки из различных процессов попытаются работать с таким мьютексом, то дальнейшее их поведение не определено. По умолчанию этот атрибут устанавливается равны м значению PTHREAD_PROCESS_PRIVATE.

Возвращаемые значения

При успешном завершении функция pthread_mutexattr_setpshared() возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

П ри успешно м завершении функция pthread_mutexattr_getpshared() возвра щ ает нулевое значение и сохраняет считанное значение атрибута process-shared объекта attr в объекте, адресуемом параметром pshared, в противном случае возвращается код ошибки, обозначающий ее характер.

Ошибки

Функции pthread_mutexattr_getpshared() и pthread_mutexattr_setpshared () м о г ут завершиться неудачно, если:

[ EINVAL]  значение, заданное параметром attr, недействительно.

Функция pthread_mutexattr_setpshared () м ожет завершиться неу д ачно, если:

[EINVAL] новое значение, за д анное д ля атрибута, попадает вне диапазона значений, действительных д ля этого атрибута.

Эти функции не возвра щ ают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_cond_destroy(), pthread_create(), pthread_mutex_destroy(), pthread_mutexattr_destroy (), то м Base Definidons стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширение м POSIX Threads Extension.

Issue 6

Функции pthread_mutexattr_getpshared() и pthread_mutexattr_setpshared () от м ечены как часть опций Threads и Thread Process-Shared Synchronization.

В целях согласования со стандарто м ISO/IEC 9899: 1999 в прототип функции pthread_mutexattr_getpshared () было добавлено ключевое слово restrict.

Имя

pthread_mutexattr_gettype, pthread_mutexattr_settype — функции считывания и установки атрибута type.

Синопсис

XSI #include <pthread.h>

int pthread_mutexattr_gettype (

const pthread_mutexattr_t *restrict attr, int *restrict type); int pthread_mutexattr_settype (

pthread_mutexattr_t *attr, int type);

Описание

Функции pthread_mutexattr_gettype() и pthread_mutexattr_settype() используются для считывания и установки соответственно атрибута type. Этот атрибут задается при вызове этих функций в пара м етре type. По у м олчанию атрибут type устанавливается равны м значению PTHREAD_MUTEX_DEFAULT.

Атрибут type содержит тип м ьютекса. Допусти м ы м и значения м и атрибута type м огут быть следую щ ие:

PTHREAD_MUTEX_NORMAL

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

PTHREAD_MUTEX_ERRORCHECK

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

PTHREAD_MUTEX_RECURS IVE

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

PTHREAD_MUTEX_DEFAULT

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

Возвращаемые значения

При успешном завершении функция pthread_mutexattr_gettype () возвращает нулевое значение и сохраняет значение атрибута type, считанное из объекта attr, в объекте, адресуемом параметром type; в противном случае она возвращает код ошибки, обозначающий ее характер.

При успешном завершении функция pthread_mutexattr_settype () возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_mutexattr_settype () завершится неудачно, если:

[EINVAL]  значение, заданное пара м етро м type, недействительно.

Функции pthread_mutexattr_gettype () и pthread_mutexattr_settype () могутзавершиться неудачно, если:

[EINVAL]  значение, заданное пара м етро м attr, недействительно.

Эти функции не возвра щ ают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

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

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_cond_timedwait(), том Base Definitions стандарта IEEE Std 1003.1-200l, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Issue 6

Приложен список опечаток Open Group Corrigendum U033/3. Был отредактирован раздел «Синопсис» для функции pthread_mutexattr_gettype (), в результате чего первый аргумент получил тип const pthread_mutexattr_t*.

В целях согласования со стандартом ISO/IEC 9899: 1999 в прототип функции pthread_mutexattr_gettype было добавлено ключевое слово restrict.

Имя

pthread_once — функция д ина м ической инициализации пакетов.

Синопсис

THR #include <pthread.h>

int pthread_once (pthread_once_t *once_control, void (*init_rout_ne) (void)); pthread_once_t once_control = PTHREAD_ONCE_INIT;

Описание

При перво м обра щ ении к функции pthread_once() любы м потоко м процесса с заданны м пара м етро м once_control будет вызвана функция ini t_routine без аргументов. Последующие обра щ ения к функции pthread_once () с те м же пара м етро м once_control не вызывают функцию init_routin e. Возвра щ ение из функции pthread_once() означает, что функция init_routine выполнена. Пара м етр once_control определяет, вызываласьли соответствую щ ал функция инициализации.

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

Константа PTHREAD_ONCE_INIT определяется в заголовке <pthread. h>.

Поведение функции pthread_once () будет неопределенны м, если пара м етр once_control и м еет авто м атический класс па м яти (объекты этого класса раз м е щ аются в стеке и инициализируются всякий раз при входе в блок, где они объявлены, иразрушаются при выходе из этого блока) или не инициализирован константой PTHREAD_ONCE_INIT.

Возвращаемое значение

При успешно м завершении функция pthread_once () возвра щ ает нулевое значение; в противно м случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_once() м ожет завершиться неудачно, если:

[EINVAL] значения, заданные пара м етра м и once_control или init_routine, недействительны. Функция pthread_once() не возвращает код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

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

static int random_is_initialized = 0;

extern int initialize_random ();

int random_function () {

if (random_is_initialized == 0) {

initialize_random ();

random_is_initialized = 1;

}

... /* Операции, выполняемые после инициализации. */

}

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

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

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

#include <pthread.h>

static pthread_once_t random_is_initialized =PTHREAD_ONCE_INIT;

extern int initialize_random();

int random_function()

{

(void) pthread_once (&random_is_initialized,initialize_random); ...

/* Операции, выполняемые после инициализации. */

}

Обратите вни м ание на то, что тип pthread_once_t не может быть массивом, поскольку для некоторых компиляторов конструкция &<array_name> неприемлема.

Будущие направления

Отсутствуют.

Смотри также

Том Base Definitions стандарта1ЕЕЕStd 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширением POSIX Threads Extension.

Issue 6

Функция pthread_once () от м ечена как часть опции Threads.

Был добавлен код ошибки [EINVAL], возвращаемый при неудачном завершении функции в случае, если хотя бы один из аргументов недействителен.

Имя

pthread_rwlock_destroy, pthread_rwlock_init — функции разрушения и инициализации объекта блокировки для чтения и записи.

Синопсис

THR

#include <pthread.h>

int pthread_rvlock_destroy(pthread_rwlock_t *rwlock);

int pthread_rwlock_init( pthread_rwlock_t *restrict rwlock, const pthread_rwlockattr_t *restrict attr);

Описание

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

Функция pthread_rwlock_init() выделяет любые ресурсы, необходимые для использования объекта блокировки для чтения и записи, адресуемого пара м етром rwlock, и инициализирует его (он переходит в незаблокированное состояние) с использованием объекта атрибутов, адресуе м ого пара м етро м attr. Если пара м етр attr содержит значение NULL, для блокировки чтения и записи будут использованы атрибуты, действующие по у м олчанию; т.е. результат в это м случае равносилен передаче адреса объекта, содержащего стандартные атрибуты блокировки для чтения и записи. После первой инициализации объект блокировки можно использовать любое число раз без повторной инициализации. Результаты не определены, если функция pthread_rwlock_init () вызвана с заданием уже инициализированного объекта блокировки. Результаты не определены, если объект блокировки для чтения и записи используется без предварительной инициализации.

При неудачном выполнении функции pthread_rwlock_init() объект, адресуемый параметро м rwlock, остается неинициализированны м, а содержимое параметра rwlock — неопределенным.

Для выполнения синхронизации можно использовать только объект, адресуемый параметром rwlock. Результат ссылки на копии этого объекта в вызовах функций pthread_rwlock_destroy(), pthread_rwlock_rdlock(), pthread_rwlock_ti~ medrdlock(), pthread_rwlock_timedwrlock(), pthread_rwlock_tryrdlock(), pthread_rwlock_trywrlock (), pthread_rwlock_unlock () или pthread_rwlock_ wrlock () не опре д елен.

Возвращаемые значения

При успешно м завершении функции pthread_rwlock_destroy() и pthread_rwlock_init () возвра щ ают нулевое значение; в противно м случае — код ошибки, обозначаю щ ий ее характер.

Проверка на наличие ошибок с кода м и [EBUSY] и [EINVAL] реализована (если реализована вооб щ е) так, как будто она выполняется в самом начале работы каждой функции, и код ошибки в случае ее обнаружения возвращается до модификации состояния объекта блокировки чтения и записи, заданного параметром rwlock.

Ошибки

Функция pthread_rwlock_destroy () м ожет завершиться неудачно, если:

[EBUSY]  реализация обнаружила попытку разрушить заблокированный объект, адресуе м ый пара м етро м rwlock;

[EINVAL]  значение, за д анное пара м етро м rwlock, не д ействительно.

Функция pthread_rwlock_init () завершится неу д ачно, если:

[EAGAIN]  систе м а испытывает не д остаток в ресурсах (не и м еется в виду память), необходимых для инициализации еще одного объекта блокировки для чтения и записи;

[ENOMEM]  для инициализации объекта блокировки для чтения и записи недостаточно существующей памяти;

[EPERM]  инициатор вызова не обладает привилегиями для выполнения этой операции.

Функция pthread_rwlock_init () м ожет завершиться неу д ачно, если:

[EBUSY]  реализация обнаружила попытку повторно инициализировать объект блокировки, адресуе м ый пара м етро м rwlock, которой был ранее инициализирован, но еще не разрушен;

[EINVAL]  значение, заданное пара м етро м attr, не д ействительно.

Эти функции не возвращают ко д ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_rwlock_rdlock (), pthread_rwlock_timedrdlock (), pthread_rwlock_timedwrlock (), pthread_rwlock_tryrdlock (), pthread_rwlock_trywrlock(), pthread_rwlock_unlock(), pthread_rwlock_wrlock (), том Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Issue 6

Для согласования со стандартом IEEE Std 1003.1j-2000 были внесены следующие изменения.

• В разделе «Синопсис» изменена метка. Новая метка THR обозначает, что рассматриваемые функции теперь являются частью опции Threads (ранее они относились к опции Read-Write Locks стандарта IEEE Std 1003.1j-2000, а также считались частью дополнения XSI). В раздел «Синопсис» также не входит макрос инициализации.

• Раздел «Описание» отредактирован следующим образом:

— явно отмечено выделение ресурсов при инициализации объекта блокировки для чтения и записи;

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

• В раздел «Ошибки» добавлен код ошибки [EINVAL] , означающий, что при вызове функции pthread_rwlock_init () значение, заданное пара м етро м attr, было недействительно.

• Отредактирован раздел «Смотри также».

В целях согласования со стандарто м ISO/IEC 9899: 1999 в прототип функции pthread_rwlock_init () было добавлено ключевое слово restrict.

Имя

pthread_rwlock_rdlock, pthread_rwlock_tryrdlock— функции блокирования объекта блокировки чтения-записи для обеспечения чтения.

Синопсис

THR

#include <pthread.h>

int pthread_rwlock_rdlock (pthread_rwlock_t *rwlock) ; int pthread_rwlock_tryrdlock (pthread_rwlock_t *rwlock) ;

Описание

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

TPS Если поддерживается опция Thread Execution Scheduling и потоки, участвующие в данной блокировке, выполняются с использованием стратегий планирования SCHED_FIFO или SCHED_RR, то вызывающий поток не получит эту блокировку, если ее удерживает записывающий поток или если по этому объекту блокировки заблокированы записывающие потоки такого же или более высокого приоритета; в противном случае вызывающий поток получит блокировку.

TSP TSP Если поддерживается опция Thread Execution Scheduling и потоки, участвующие в данной блокировке, выполняются с использованием стратегии планирования SCHED_SPORADIC, то вызывающий поток не получит эту блокировку, если ее удерживает записывающий поток или если по этому объекту блокировки заблокированы записывающие потоки такого же или более высокого приоритета; в противном случае вызывающий поток получит блокировку.

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

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

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

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

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

Возвращаемые значения

При успешном завершении функция pthread_rwlock_rdlock() возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Функция pthread_rwlock_tryrdlock () возвращает нулевое значение, если блокировка для чтения по объекту блокировки чтения-записи, адресуемому параметром rwloc, предоставлена. В противном случае возвращается код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_rwlock_tryrdlock () завершится неудачно, если:

[EBUSY] блокировка чтения-записи не могла быть предоставлена для чтения, поскольку удерживает блокировку записывающий поток, или по этому объекту заблокирован записывающий поток с соответствующим приоритетом .

Функции pthread_rwlock_rdlock() и pthread_rwlock_tryrdlock() м огут завершиться неудачно, если:

[EINVAL] значение, заданное пара м етро м rwlock, не относится к инициализированно м у объекту блокировки чтения-записи;

[EAGAIN] блокировка не м огла быть предоставлена для чтения, поскольку превышено м акси м альное число блокировок чтения по объекту, адресуе м о м у пара м етро м rwlock.

Функция pthread_rwlock_rdlock () м ожет завершиться неудачно, если:

[EDEADLK] теку щ ий поток уже удерживает объект блокировки чтения-записи для обеспечения записи. Эти функции не возвра щ ают код ошибки [EINTR].

Примеры

Отсутствуют.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_rwlock_destroy (), pthread_rwlock_timedrdlock (), pthread_rwlock_timedwrlock (), pthread_rwlock_trywrlock (), pthread_rwlock_unlock (), pthread_rwlock_wrlock (), то м Base Definitions crannapTalEEEStd 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Issue 6

Для согласования со стандарто м IEEE Std 1003.1j-2000 были внесены следую щ ие изменения.

• В разделе «Синопсис» была из м енена м етка. Новая м етка THR означает, что расс м атривае м ые функции теперь являются частью опции Threads (ранее они относились к опции Read-Write Locks стандарта IEEE Std 1003.1j-2000, а также считались частью дополнения XSI).

• Раздел «Описание» был отредактирован следую щ и м образо м:

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

- разъяснена воз м ожная причина неудачного завершения функции pthread_rwlock_tryrdlock();

- добавлен абзац, в которо м говорится о при м енении м акси м ального количество блокировок для обеспечения чтения.

• Был м одифицирован раздел «Ошибки», посвященный описанию кода ошибки [EBUSY] : теперь предлагается принять во внимание приоритет записывающих потоков. Удален абзац, посвященный описанию кода ошибки [EDEADLK] , возвращаемому функцией pthread_rwlock_tryrdlock ().

• Был отредактирован раздел «Смотри также».

Замечания по использованию

Как упо м иналось в то м е Base Definitions стандарта IEEE Std 1003.1-2001 (Se c tion 3.285, Priority Inversion), приложения, которые используют эти функции, м огут подвергнуться инверсии приоритетов.

Имя

pthread_rwlock_timedrdlock— функция, блокирующал объект блокировки чтения-записи для обеспечения чтения.

Синопсис

THR #include <pthread.h> TMO #include <time.h>

int pthread_rwlock_timedrdlock (

pthread_rwlock_t *restrict rwlock,

const struct timespec *restrict abs_timeout);

Описание

Функция pthread_rwlock_timedrdlock () при м еняет блокировку для обеспечения чтения к объекту блокировки чтения-записи, адресуе м о м у пара м етро м rwlock, подобно функции pthread_rwlock_rdlock (). Однако, если блокировка не может быть предоставлена без ожидания, пока другие потоки не освободят ее, это ожидание будет прервано, когда истечет заданный интервал времени. Интервал времени истекает, когда наступит абсолютное вре м я, заданное пара м етро м abs_timeout (т.е. когда показания вре м ени на используе м ых в систе м е часах станут равны м и или превысят значение abs_timeout), или если абсолютное вре м я, заданное пара м етро м abs_ timeou t, уже наступило в м о м ент вызова.

TMR Если по д держивается опция Timers, отсчет интервала вре м ени происходит с использование м часов CLOCK_REALTIME.

Если опция Timers не поддерживается, отсчет интервала времени происходит с использованием системных часов, значение которых возвращает функция time (). Разрешение для интервала времени определяется разрешением часов, которые используются для его отсчета. Тип данных timespec определяется в заголовке <time.h>. Ни при каких условиях эта функция не завершится неудачно, если блокировка может быть предоставлена немедленно. В проверке достоверности параметра abs_timeout нет никакой необходи м ости, если блокировка м ожет быть предоставлена не м едленно.

Если потоку, заблокированно м у по объекту блокировки чтения-записи при вызове функции pthread_rwlock_timedrdlock(), передается сигнал, то после его обработки поток возобновит ожидание освобождения блокировки, как если бы оно и не прерывалось.

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

Возвращаемое значение

Функция pthread_rwlock_timedrdlock() возвра щ ает нулевое значение, если блокировка для чтения по объекту блокировки чтения-записи, адресуе м о м у пара м етро м rwloc, предоставлена. В противно м случае возвращается код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_rwlock_timedrdlock () завершится неудачно, если:

[ETIMEDOUT] блокировка не м огла быть предоставлена до истечения за д анного интервала вре м ени.

Функция pthread_rwlock_timedrdlock () м ожет завершиться неу д ачно, если:

[EAGAIN]  блокировка д ля чтения не м огла быть пре д оставлена, поскольку

превышено м акси м альное число блокировок чтения по объекгу, адресуемому пара м етро м rwlock

[EDEADLK]  вызываю щ ий поток уже у д ерживает объект блокировки для обеспечения записи по объекту, адресуемому параметром rwlockr,

[EINVAL]  значение, заданное параметром rwlock, не относится к инициализированному объекту блокировки чтения-записи, или значение abs_timeout, выраженное в наносекундах, меньше нуля либо больше или равно 1000 миллионам.

Эта функция не возвращает код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Как упо м иналось в то м е Base Definitions стан д арта IEEE Std 1003.1-2001 (Section 3.285, Priority Inversion), приложения, которые используют эту функцию, могут по д вергнуться инверсии приоритетов.

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

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_rwlock_destroy(), pthread_rwlock_rdlock(), pthread_rwlock_timedwrlock(), pthread_rwlock_tryrdlock(), pthread_rwlock_trywrlock(), pthread_rwlock_unlock(), pthread_rwlock_wrlock (), то м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>, <time.h>.

Последовательность внесения изменений

Функция впервые реализована в выпуске Issue 6, основание м послужил стандарт IEEEStd 1003.1j-2000.

Имя

pthread_rwlock_timedwrlock — функция, блокирующая объект блокировки чтения-записи для обеспечения записи.

Синопсис

THR TMO

#include <pthread.h>

#include <time.h>

int pthread_rwlock_timedwrlock (

pthread_rwlock_t *restrict rwlock,

const struct timespec *restrict abs_timeout);

Описание

Функция pthread_rwlock_timedwrlock () при м еняет блокировку для обеспечения записи к объекту блокировки чтения-записи, адресуемому пара м етро м rwlock, подобно функции pthread_rwlock_wrlock (). Однако, если блокировка не м ожет быть предоставлена без ожидания, пока другие потоки не освободят ее, это ожидание будет прервано, когда истечет заданный интервал вре м ени. Интервал вре м ени истекает, когда наступит абсолютное вре м я, заданное пара м етро м abs_timeout (т.е. когда показания времени на используемых в системе часах станут равными или превысят значение abs_timeout), или если абсолютное вре м я, заданное пара м етро м abs_timeout, уже наступило в момент вызова.

TMR Если поддерживается опция Timers, отсчет интервала вре м ени происходит с использование м часов CLOCK_REALTIME.

Если опция Timers не поддерживается, отсчет интервала времени происходит с использованием системных часов, значение которых возвращает функция time (). Разрешение для интервала времени определяется разрешением часов, которые используются для его отсчета. Тип данных timespec определяется в заголовке <time.h>. Ни при каких условиях эта функция не завершится неудачно, если блокировка может быть предоставлена немедленно. В проверке достоверности параметра abs_timeout нет никакой необходимости, если блокировка может быть предоставлена немедленно.

Если потоку, заблокированно м у по объекту блокировки чтения-записи при вызове функции pthread_rwlock_timedwrlock(), передается сигнал, то после его обработки поток возобновит ожидание освобождения блокировки, как если бы оно и не прерывалось.

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

Возвращаемое значение

Функция pthread_rwlock_timedwrlock () возвра щ ает нулевое значение, если блокировка для записи по объекту блокировки чтения-записи, адресуе м о м у пара м етро м rwloc, предоставлена. В противно м случае возвращается код ошибки, обозначающий ее характер.

Ошибки

Фу н кция pthread_rwlock_timedwrlock () завершится неудачно, если:

[ETIMEDOUT] блокировка не м огла быть предоставлена до истечения заданного интервала вре м ени.

Функция pthread_rwlock_timedwrlock () м ожет завершиться неудачно, если:

[EDEADLK]  вызываю щ ий поток уже удерживает объект блокировки по объекту,

адресуе м о м у пара м етро м rwlock;

[EINVAL]  значение, заданное пара м етро м rwlock, не относится к инициализированно м у объекту блокировки чтения-записи, или значение abs_timeout, выраженное в наносекундах, меньше нуля либо больше или равно 1000 миллионам.

Эта функция не возвра щ ает код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Как упоминалось в томе Base Definitions стандарта IEEE Std 1003.1-2001 (Section 3.285, Priority Inversion), приложения, которые используют эту функцию, могут подвергнуться инверсии приоритетов.

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

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_rwlock_destroy(),pthread_rwlock_rdlock(), pthread_rwlock_timedrdlock(), pthread_rwlock_tryrdlock(), pthread_rwlock_trywrlock (), pthread_rwlock_unlock (), pthread_rwlock_wrlock (), том Base Definitions стандарта IEEE Std 1003.1-2001, <pthread. h>, <t ime. h>.

Последовательность внесения изменений

Функция впервые реализована в выпуске Issue 6, основание м послужил стандарт IEEEStd 1003.1j-2000.

Имя

pthread_rwlock_trywrlock, pthread_rwlock_wrlock — функции, блокирующие объект блокировки чтения-записи для обеспечения записи.

Синопсис

THR

#include <pthread.h>

int pthread_rwlock_trywrlock (pthread_rwlock_t *rwlock);

int pthread_rwlock_wrlock (pthread_rwlock_t *rwlock);

Описание

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

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

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

Возвращаемые значения

Функция pthread_rwlock_trywrlock() возвра щ ает нулевое значение, если блокировка для записи по объекту блокировки чтения-записи, адресуе м о м у пара м етро м rwloc, предоставлена. В противно м случае возвра щ ается код ошибки, обозначаю щ ий ее характер.

При успешном завершении функция pthread_rwlock_wrlock () возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_rwlock_trywrlock () завершится неудачно, если:

[EBUSY] блокировка чтения-записи не м огла быть предоставлена для записи, поскольку заданный объект блокировки уже заблокирован для чтения или записи.

Функции pthread_rwlock_wrlock() и pthread_rwlock_trywrlock() м огут завершиться неудачно, если:

[EINVAL] значение, заданное пара м етро м rwlock, не относится к инициализированно м у объекту блокировки чтения-записи.

Функция pthread_rwlock_wrlock () м ожет завершиться неудачно, если:

[EDEADLK] теку щ ий поток уже удерживает объект блокировки чтения-записи для обеспечения записи или чтения.

Эти функции не возвра щ ают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Как упо м иналось в то м е Base Definitions стандарта IEEE Std 1003.1-2001 (Section 3.285, Priority Inversion), приложения, которые используют эти функции, м огут подвергнуться инверсии приоритетов.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_rwlock_destroy(),pthread_rwlock_rdlock(), pthread_rwlock_timedrdlock (), pthread_rwlock_timedwrlock (), pthread_rwlock_tryrdlock(),pthread_rwlock_unlock(), том Base Definitions cтaндapтaIEEEStd 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в вылуске Issue 5.

Issue 6

Для согласования со стандарто м IEEE Std 1003.1j-2000 были внесены следующие изменения:

• В разделе «Синопсис» была из м енена м етка. Новал м етка THR означает, что расс м атривае м ые функции теперь являются частью опции Threads (ранее они от-

носились к опции Read-Write Locks стандарта IEEE Std 1003.1j-2000, а также считались частью дополнения XSI).

• Из раздела «Ошибки» удален абзац, посвященный описанию кода ошибки [EDEADLK] , возвращаемому функцией pthread_rwlock_trywrlock ().

• Был отредактирован раздел «С м отри также».

Имя

pthread_rwlock_unlock— функция разблокирования объекта блокировки чтения-записи.

Синопсис

THR

#include <pthread.h>

int pthread_rwlock_unlock(pthread_rwlock_t *rwlock);

Описание

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

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

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

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

TPS Если потоки, ожидающие освобождения блокировки, выполняются в соответствии со стратегиями планирования SCHED_FIFO, SCHED_RR или SCHED_SPORADIC, то при поддержке опции Thread Execution Scheduling после освобождения этой блокировки потоки получат блокировку в порядке следования их приоритетов. Для потоков с одинаковыми приоритетами блокировки для записи имеют преимущество перед блокировками для чтения.

Если опция Thread Execution Scheduling не поддерживается, то будут ли блокировки для записи иметь преимущество перед блокировками для чтения, определяется конкретной реализацией.

Результаты не определены, если эта функция вызывается с неинициализированным объектом блокировки чтения-записи.

Возвращаемое значение

При успешном завершении функция pthread_rwlock_unlock () возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_rwlock_unlock () м ожет завершиться неудачно, если:

[EINVAL] значение, заданное пара м етро м rwlock, не относится к инициализированно м у объекту блокировки чтения-записи

[EPERM] текущий поток не удерживает объект блокировки чтения-записи для обеспечения записи или чтения.

Функция pthread_rwlock_unlock () не возвра щ ает код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_rwlock_destroy(), pthread_rwlock_rdlock(), pthread_rwlock_timedrdlock (), pthread_rwlock_timedwrlock (), pthread_rwlock_tryrdlock(), pthread_rwlock_trywrlock(), pthread_rwlock_wrlock (), то м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в вылуске Issue 5. Issue 6

Для согласования со стандартом IEEE Std 1003.1j-2000 были внесены следующие изменения.

• В разделе «Синопсис» была изменена метка. Новал метка THR означает, что рассматриваемые функции теперь являются частью опции Threads (ранее они

относились к опции Read-Write Locks стандарта IEEE Std 1003.1j-2000, а также считались частью дополнения XSI).

• Раздел «Описание» был отредактирован следующим образом:

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

— удалена концепция владельца блокировки чтения-записи.

• Был отредактирован раздел «Смотри также».

Имя

pthread_rwlockattr_destroy, pthread_rwlockattr_init— функции разрушения и инициализации объекта атрибутов для блокировки чтения-записи.

Синопсис

THR #include <pthread.h>

int pthread_rwlockattr_destroy(

pthread_rwlockattr_t *attr); int pthread_rwlockattr_init(pthread_rwlockattr_t *attr);

Описание

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

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

Если функция pthread_rwlockattr_init () вызывается для уже инициализированного объекта атрибутов attr, то результаты вызова этой функции не определены.

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

Возвращаемые значения

При успешно м завершении функции pthread_rwlockattr_destroy() и pthread_rwlockattr_init() возвращают нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функция pthread_rwlockattr_destroy () может завершиться неудачно, если:

[EINVAL]  значение, заданное параметром attr, недействительно.

Функция pthread_rwlockattr_init () завершится неудачно, если:

[ENOMEM]  для инициализации объекта атрибутов блокировки чтения-записи недостаточно существующей памяти.

Эти функции не возвращают код ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_rwlock_destroy(), pthread_rwlockattr_getpshared(), pthread_rwlockattr_setpshared (), то м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5.

Issue 6

Для согласования со стандартом IEEE Std 1003.1j-2000 были внесены следующие изменения.

• В разделе «Синопсис» была изменена метка. Новал метка THR означает, что рассматриваемые функции теперь являются частью опции Threads (ранее они относились к опции Read-Write Locks стандарта IEEE Std 1003.1j-2000, а также считались частью дополнения XSI).

• Был отредактирован раздел «Смотри также».

Имя

pthread_rwlockattr_getpshared, pthread_rwlockattr_setpshared —функции считывания и установки атрибута process-shared в объекте атрибутов блокировки чтения-записи.

Синопсис

THRTSH #include <pthread.h>

int pthread_rwlockattr_getpshared(

const pthread_rwlockattr_t *restrict attr, int *restrict pshared) ; int pthread_rwlockattr_setpshared(

pthread_rwlockattr_t * attr, int pshared);

Описание

Функция pthread_rwlockattr_getpshared() используется для получения значения атрибута process-shared из инициализированного объекта атрибутов, адресуе м ого пара м етро м attr. Функция pthread_rwlockattr_setpshared () позволяет установить атрибут process-shared в инициализированно м объекте атрибутов, адресуе м о м пара м етро м attr.

Атрибут process-sharedycтанaвливaeтcя равны м значению PTHREAD_PROCESS_ SHARED, чтобы разрешить использование объекта блокировки чтения-записи любы м потоко м, и м ею щ и м доступ к области па м яти, в которой он раз м е щ ен, даже если эта область па м яти разделяется нескольки м и процесса м и. Если же атрибут process-shared равен значению PTHREAD_PROCESS_PRIVATE, объект блокировки чтения-записи должен использоваться только потока м и, созданны м и в одно м процессе с потоко м, который его инициализировал; если с эти м объекто м блокировки чтения-записи попытаются работать потоки из различных процессов, поведение такой програ мм ы не определено. По у м олчанию для этого атрибута устанавливается значение PTHREAD_PROCESS_PRIVATE.

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

Возвращаемые значения

При успешно м завершении функция pthread_rwlockattr_getpshared() возвра щ ает нулевое значение и сохраняет считанное значение атрибута process-shared объекта attr в объекте, адресуе м о м пара м етро м pshared\ в противно м случае возвра щ ается код ошибки, обозначающий ее характер.

При успешно м завершении функция pthread_rwlockattr_setpshared() возвращает нулевое значение; в противном случае — код ошибки, обозначающий ее характер.

Ошибки

Функции pthread_rwlockattr_getpshared() и pthread_rwlockattr_ setpshared () м огут завершиться неудачно, если:

[ EINVAL ] значение, заданное пара м етро м attr, недействительно.

Функция pthread_rwlockattr_setpshared () м ожетзавершиться неудачно, если:

[EINVAL] новое значение, заданное для атрибута, попа д ает вне д иапазона значений, д ействительных д ля этого атрибута.

Эти функции не возвра щ ают ко д ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Отсутствует.

Будущие направления

Отсутствуют.

Смотри также

pthread_rwlock_destroy(),pthread_rwlockattr_destroy(), pthread_rwlockattr_init (), то м Base Definitions стан д арта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5.

Issue 6

Для согласования со стан д арто м IEEE Std 1003.1j-2000 были внесены сле д ую щ ие из м енения.

• В разделе «Синопсис» была изменена метка. Новая метка THR означает, что расс м атривае м ые функции теперь являются частью опции Threads (ранее они относились к опции Read-Write Locks стан д арта IEEE Std 1003.1j-2000, а также считались частью д ополнения XSI).

• В разделе «Описание» отмечено, что дополнительные атрибуты определяются конкретной реализацией.

• Был отредактирован раздел «Смотри также».

В целях согласования со стандартом ISO/IEC 9899: 1999 в прототип функции pthread_rwlockattr_getpshared () было добавлено ключевое слово restrict.

Имя

pthread_self — функция получения и д ентификационного но м ера (ID) вызывающего потока.

Синопсис

THR #include <pthread.h>

pthread_t pthread_self {void);

Описание

Функция pthread_self() возвра щ ает и д ентификационный но м ер (ID) вызываю щ его потока.

Возвращаемое значение

См. раз д ел «Описание».

Ошибки

Ко д ы ошибок не опре д елены.

Функция pthread_self () не возвра щ ает ко д ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Функция pthread_self() обеспечивает воз м ожность, аналогичную функции getpid () д ля процессов, поэто м у и логическое обоснование у нее такое же: при вызове функции соз д ания потока и д ентификационный но м ер (ID) соз д анно м у потоку авто м атически не пре д оставляется.

Будущие направления

Отсутствуют.

Смотри также

pthread_create (), pthread_equal (), то м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функция впервые реализована в выпуске Issue 5. Включена для согласования с расширение м POSIX Threads Extension.

Issue 6

Функция pthread_self () от м ечена как часть опции Threads.

Имя

pthread_setcancelstate, pthread_setcanceltype, pthread_testcancel— функции установки состояния от м ены (аннулирования) потока.

Синопсис

THR #include <pthread.h>

int pthread_setcancelstate(int state, int *oldstate);

int pthread_setcanceltype(int type, int *oldtype);

void pthread_testcancel(void);

Описание

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

Функция pthread_setcanceltype () о д новре м енно устанавливает тип от м ены вызываю щ его потока равны м значению, за д анно м у пара м етро м type, и возвра щ ает значение предыдущего типа от м ены в пере м енной, а д ресуе м ой пара м етро м oldtype. Допусти м ы м и значения м и д ля пара м етра type являются PTHREAD_CANCEL_ DEFERRED и PTHREAD_CANCEL_ASYNCHRONOUS.

Состояние и тип отмены любых создаваемых потоков, включал поток, в которо м впервые вызывается функция main(), устанавливаются равны м и значения м PTHREAD_CANCEL_ENABLE и PTHREAD_CANCEL_DEFERRED соответственно.

Функция pthread_testcancel () пре д назначена д ля соз д ания точки от м ены в вызываю щ е м потоке. Функция pthread_testcancel () не и м еет эффекта, если от м ена потока запре щ ена.

Возвращаемые значения

При успешно м завершении функции pthread_setcancelstate() и pthread_ setcanceltype () возвра щ ают нулевое значение; в противно м случае возвра щ ается ко д ошибки, обозначаю щ ий ее характер.

Ошибки

Функция pthread_setcancelstate () м ожет завершиться неу д ачно, если:

[EINVAL] за д анный пара м етр state не со д ержит ни значения PTHREAD_ CANCEL_ENABLE , низначения PTHREAD_CANCEL_DI SABLE.

Функция pthread_setcanceltype () м ожет завершиться неу д ачно, если:

[EINVAL] за д анный пара м етр type не со д ержит ни значения PTHREAD_ CANCEL_DEFERRED, ни значения PTHREAD_CANCEL_ASYNCHRONOUS.

Эти функции не возвра щ ают ко д ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

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

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

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

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

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

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

Будущие направления

Отсутствуют.

Смотри также

pthread_cancel(), то м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread.h>.

Последовательность внесения изменений

Функции впервые реализованы в выпуске Issue 5. Включены для согласования с расширение м POSIX Threads Extension.

Issue 6

Функции pthread_setcancelstate (), pthread_setcanceltype () и pthread_ testcancel () от м ечены как часть опции Threads.

Имя

pthread_setschedprio — функция д ина м ического д оступа к пара м етра м планирования потока (REALTIME THREADS).

Синопсис

THRTPS #include <pthread.h>

int pthread_setschedprio(pthread_t thread, int prio);

Описание

Функция pthread_setschedprio () используется д ля установки приоритета планирования равны м значению, заданно м у пара м етро м prio, для потока, идентификационный но м ер (ID) которого задан пара м етро м thread.

В случае неудачного завершения функции pthread_setschedprio () приоритет планирования заданного потока останется без из м енения.

Возвращаемое значение

При успешно м завершении функция pthread_setschedprio () возвра щ ает нулевое значение; в противно м случае возвра щ ается код ошибки, обозначаю щ ий ее характер.

Ошибки

Функция pthread_setschedprio () м ожет завершиться неудачно, если:

[EINVAL] значение пара м етра prio не действительно для стратегии планирования заданного потока;

[ENOTSUP] была сделана попытка установить приоритет равны м значению, которое не поддерживается;

[EPERM] инициатор вызова не и м еет соответствую щ его разрешения на установку пара м етров стратегии планирования за д анного потока;

[EPERM] реализация не позволяет приложению м о д ифицировать приоритет, устанавливая его равны м за д анно м у значению;

[ESRCH] значение, за д анное пара м етро м thread, не относится к су щ ествую щ е м у потоку.

Функция pthread_setschedprio () не возвра щ ает ко д ошибки [EINTR].

Примеры

Отсутствуют.

Замечания по использованию

Отсутствуют.

Логическое обоснование

Функция pthread_setschedprio() обеспечивает для приложения воз м ожность вре м енно г о увеличения приоритета с последую щ и м ero понижение м без нежелательного побочного эффекта, выражае м ого в установке други м и потока м и такого же приоритета. Это нужно, если приложение должно реализовать такие собственные стратегии для ограничения инверсии приоритетов, как наследование приоритетов или использование предельных значений приоритетов. Эта воз м ожность особенно важна, если реализация не по д держивает опции Thread Priority Protection или Thread Priority Inheritance, но даже в случае их по д держки эту воз м ожность необходи м о использовать, если приложение обязано привязывать наследование приоритетов к использованию таких ресурсов, как се м афоры.

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

Будущие направления

Отсутствуют.

Смотри также

pthread_getschedparam(), то м Base Definitions стандарта IEEE Std 1003.1-2001, <pthread. h>.

Последовательность внесения изменений

Функция впервые реализована в выпуске Issue 6. Включена в качестве реакции на интерпретацию IEEE PASC Interpretation 1003.1 #96.

СПИСОК ЛИТЕРАТУРЫ

1. Audi, Robert. Action, Intention, andReason. Ithaca, N. Y.: Cornell University Press, 1993.

2. Axford, Tom. Concurrent Programming: Fundamental Techniques for Real-Time and ParalMSoftwareDesign, Chichester, U. K.:JohnWiley, 1989.

3. Baase, Sarah. ComputerAlgorithms: Introduction to Design andAnalysis. 2nd ed. Reading, Mass.:Addison-Wesley, 1988.

4. Barfield, Woodrow, and Thomas A. Furnell III. Virtual Environments and Advanced InterfaceDesign. New York: Oxford University Press, 1995.

5. Binkley, Robert, Bronaugh, Richard, and Ausonio Marras. Agent, Action, andReason. Toronto: UniversityofToronto Press, 1971.

6. Booch, Grady, James Rumbaugh, and IvarJacobson. The Unified Modeling Language UserGuide. Boston: Addison-Wesley, 1999.

7. Bowan, Howard, andJohn Derrick. FormalMethods forDistributedProcessing: A Survey of Object-OrientedApproaches. NewYork: Cambridge University Press, 2001.

8. Brewka, Gerhard,Jurgen Diz, and Kurt Konolige. Nonmonotonic Reasoning. Stanford, Calif.: CSLI Publications, 1997.

9. Carroll, Martin D., and Margaret A. Ellis. Designing and CodingReusabh C++. Reading, Mass.: Addison-Wesley, 1995.

10. Cassell, Justine, Joseph Sullivan, Scott Prevost, and Elizabeth Churchill. Embodied ConversationalAgents. Cambridge, Mass.: MIT Press, 2000.

11. Chellas, Brian F. ModalLogic: An Introduction. New York: Cambridge University Press, 1980.

12. Coplien,James O. MuUi-Paradigm Design for C++. Reading, Mass.: Addison-Wesley, 1999.

13. Cormen, Thomas, Charles Leiserson, and Ronald Rivet. Introduction to Algorithms. Cambridge, Mass.: MIT Press, 1995.

14. Englemore, Robert, and Tony Morgan. BUickboard Systems. Wokingham, England: Addison-Wesley, 1988.

15. Garg, Vijay K. Principhs ofDistnbutedSystems. Norwell, Mass.: KluwerAcademic, 1996.

16. Geist, A1, Adam Beguelin, Jack Dongarra, Weicheng Jiang, Robert Manchek, and VaidySinderman. PVM:ParaUelVirtualMachine. London, England: MITPress, 1994.

17. Goodheart, Berny, andJames Cox. The Magic Garden ExpUiined: The Internak of Unix System VReUase4. New York: Prentice Hall, 1994.

18. Gropp, William, Steven Huss-Lederman, Andrew Lumsdaine, Ewing Lusk, Bill Nitzberg, William Saphir, and Marc Snir. MPI: The Compkte Reference. Vol. 2. Cambridge, Mass.: MIT Press, 1998.

19. Heath, Michael T. Scientific Computing: An Introduction Survey. New York: McGraw-Hill.

20. Henning, Michi, and Steve Vinoski. Advanced COBRA Programming with C++. Reading, Mass.: Addison-Wesley, 1999.

21. Hintikka,Jakko, and Merrill Hintikka. The Logic ofEpistemoU>gy and the EpistemoU>gy of LogTC.Amsterdam: KluwerAcademic, 1989.

22. Horty,John F. Agency andDeonticLogic. New York: Oxford University Press, 2001.

23. Hughes, Cameron, and Tracey Hughes. Mastering the Standard C++ CJmses. New York: JohnWiley, 1990.

24. Hughes, Cameron, and Tracey Hughes. Object-OrientedMuUithreading Using C++. New York:JohnWiley, 1997.

25. Hughes, Cameron, and Tracey Hughes. Linux Rapid Application Devebpment. Foster City, Calif.: M & T Books, 2000.

26. International Standard Organization. Information Technobgy: Portabk Operating System Interface. Pt. 1 System Application Program Interface. 2nd ed. Std 1003.1 ANSI/IEEE. 1996.

27. Josuttis, Nicolai M. The C++ Standard Boston: Addison-Wesley, 1999.

28. Koeing, Andrew, and Barbara Moo. Ruminations on C++. Reading, Mass.: Addison-Wesley, 1997.

29. Krishnamoorthy, C. S., and S. Rajeev. Artificial Intelligence and Expert Systems for Engineers. Boca Raton, Fla.: CRC Press, 1996.

30. Lewis, Ted, Glenn Andert, Paul Calder, Erich Gamma, Wolfgang Press, Larcy Rosenstein, and Kraus, Sarit. Strategic Negotiation in MuUitangent Environments. London: МГГ Press, 2001.

31. Luger, George F. ArtificialInteUigence. 4th ed. England: Addison-Wesley, 2002.

32. Mandrioli Dino, and Carlo Ghezzi. Theoretical Foundations of Computer Science. New York:JohnWiley, 1987.

33. Nielsen, Michael A., and Isaac L. Chuang. Quantum Computation and Quantum Information. New York: Cambridge University Press, 2000.

34. Patel, Mukesh J., Vasant Honavar, and Karthik Balakrishnan. Advances in the Evolutionary SynthesisofIntelligentAgents. Cambridge, Mass.: МГГ Press, 2001.

35. Picard, Rosalind. Affective Computing. London: MIT Press, 1997.

36. Rescher, Nicholas, and Alasdir Urquhart. Temporal Logic. New York: Springer-Verlag, 1971.

37. Robbins, Kay A., and Steven Robbins. Practical Unix Programming. Upper Saddle River, N.J.: Prentice Hall, 1996.

38. Schmucker, Kurt, Ander Weinand, andJohn M. VUssides. Object-OrientedApplication Frameworks. Greenwich, Conn.: ManningPublications, 1995.

39. Singh, Наггу. Progressing to Distributed Multiprocessing. Upper Saddle River, N.J.: Prentice Hall, 1999.

40. Skillicorn, David. Foundations of ParaUel Programming. New York: Cambridge University Press, 1994.

41. Soukup, Jiri. Taming C++: Pattern Ckisses and Persistence for Large Projects. Reading, Mass.:Addison-Wesley, 1994.

42. Sterling, Thomas L.,John Salmon, DonaldJ. Becker, and Daniel F. Savarese. How to Build a Bewoulf: A Guide to ImpUmentation and Application of PC Clusters. London: MITPress, 1999.

43. Stevens, Richard W. UNIX Network Programming: Interprocess Communications. Vol. 2, 2nd ed. Upper Saddle River: Prentice Hall, 1999.

44. Stroustrup, Bjarne. TheDesign andEvohUion of C++. Reading, Mass.: Addison-Wesley, 1994.

45. Subrahmanian, V.S., Piero Bonatti,Jurgen Dix, Thomas Eiter, Sarit Kraus, Fatma Ozcan, and Robert Ross. HeterogeneousAgentSystems. Cambridge, Mass.: МГГ Press, 2000.

46. Tel, Gerard. Introduction to Distributed Algorithms. 2nd ed. New York: Cambridge University Press, 2000.

47. Thompson, WilliamJ. ComputingforScientists andEngineers. New York:John Wiley, 1992.

48. Tomas, Gerald, and Christoph W. Uebeerhuber. Visualization of Scientific ParaUel Programming. New York: Springer-Verlag, 1994.

49. Tracy, Kim W. and Peter Bouthoorn. Object-Oriented: Artificial InteVigence Using C++. NewYork: ComputerScience Press, 1997.

50. Weiss, Gerhard. MultitagentSystems. Cambridge, Mass.: MFTPress, 1999.

51. Wooldridge, Michael. ReasoningAboutRationalAgents. London: MIT Press, 2000.

Примечания:

2

IEEE— профессиональное объединение, выпускающие свои собственные стандарты; членами IEEE являются ANSI и ISO.

26

Дословный перевод man pages

27

Точнее — это единственный член, который должен быть установлен обязательно