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

Хьюз Камерон

Функция 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 м ожно было бы закодировать таки м образо м.