Параллельное и распределенное программирование на С++

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

Компромисс между контролем за ошибками и производительностью

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