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