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