Камерон Хьюз - Параллельное и распределенное программирование на С++

Такое динамическое тестирование в функции 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, .

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

Функции впервые реализованы в выпуске 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

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() возвращают нулевое значение; в противном случае — код ошибки, обозначающий ее характер.