Наконец, независимо от того, как блокировка нами применялась, нам необходим способ ее освобождения:
int pthread_rwlock_unlock(pthread_rwlock_t* lock);
После того как поток выполнил нужную операцию с ресурсом, он освобождает блокировку, вызывая функцию pthread_rwlock_unlock(). Если блокировка теперь становится доступной в режиме, который запрошен и ожидается другим потоком, то этот ждущий поток будет переведен в состояние готовности (READY).
Отметим, что мы не смогли бы реализовать такую форму синхронизации только с помощью мутекса. Мутекс рассчитан только на один поток, что было бы хорошо в случае записи (чтобы только один поток мог использовать ресурс в определенный момент времени), но оплошал бы в случае считывания, потому что не допустил бы к ресурсу более чем одного «читателя». Семафор также был бы бесполезен, потому что нельзя было бы отличить два режима доступа — применение семафора могло бы обеспечить доступ нескольких «читателей», но если бы семафором попытался завладеть «писатель», его вызов ничем бы не отличался от вызова «читателей», что вызвало бы некрасивую ситуацию с множеством «читателей» и множеством же «писателей»!
Ждущие блокировки
Другая типовая ситуация в многопоточных программах — это потребность заставить поток «ждать чего-либо». Этим «чем- либо» может являться фактически что угодно! Например, когда доступны данные от устройства, или когда конвейерная лента находится в нужной позиции, или когда данные сохранены на диск, и т.д. Еще одна хитрость этой ситуации состоит в том, что одного и того же события могут ожидать несколько потоков.
Для таких целей мы могли бы использовать либо условную переменную (condition variable), о которой речь ниже, либо, что гораздо проще, ждущую блокировку (sleepon).
Для применения ждущих блокировок надо выполнить несколько операций. Рассмотрим сначала вызовы, а затем вернемся к использованию ждущих блокировок.
int pthread_sleepon_lock(void);
int pthread_sleepon_unlock(void);
int pthread_sleepon_broadcast(void *addr);
int pthread_sleepon_signal(void *addr);
int pthread_sleepon_wait(void *addr);
He дайте префиксу pthread_ себя обмануть. Эти функции не предусмотрены стандартами POSIX.
Как было отмечено ранее, потоку может быть необходимо ждать какого-нибудь события. Наиболее очевидный выбор из представленного выше списка функций — это функция pthread_sleepon_wait(). Но сначала поток должен проверить, надо ли ждать. Давайте приведем пример. Один поток представляет собой поток-«поставщик», который получает данные от неких аппаратных средств. Другой поток — поток-«потребитель» и он неким образом обрабатывает поступающие данные. Рассмотрим сначала поток-«потребитель»:
volatile int data_ready = 0;
consumer() {
while (1) {
while (!data_ready) {
// wait
}
// Обработать данные
}
}
«Потребитель» вечно находится в своем главном обрабатывающем цикле (while(1)). Первое, что он проверяет — это флаг data_ready. Если этот флаг равен 0, это означает, что данных нет, и их надо ждать. Впоследствии поток-«производитель» должен будет как-то «разбудить» его, и тогда поток-«потребитель» должен будет повторно проверить состояние флага data_ready. Положим, что происходит именно это. Поток-«потребитель» анализирует состояние флага и определяет, что флаг равен 1, то есть данные теперь доступны. Поток-«потребитель» переходит к обработке поступивших данных, после чего он должен снова проверить, не поступили ли новые данные, и так далее.
Здесь мы можем столкнуться с новой проблемой. Как «потребителю» сбрасывать флаг data_ready согласованно с «производителем»? Очевидно, нам понадобится некоторая форма монопольного доступа к флагу, чтобы в любой момент времени только один из этих потоков мог модифицировать его. Метод, который применен в данном случае, заключается в применения мутекса, но это внутренний мутекс библиотеки ждущих блокировок, так что мы сможем обращаться к нему только с помощью двух функций: pthread_sleepon_lock() и pthread_sleepon_unlock(). Давайте модифицируем наш поток-«потребитель»:
consumer() {
while (1) {
pthread_sleepon_lock();
while (!data_ready) {
// WAIT
}
// Обработать данные
data_ready = 0;
pthread_sleepon_unlock();
}
}
Здесь мы добавили «потребителю» установку и снятие блокировки. Это означает, что потребитель может теперь надежно проверять флаг data_ready, не опасаясь гонок, а также надежно его устанавливать.
Великолепно! А как насчет собственно процесса ожидания? Как мы и предполагали ранее, там действительно применяется вызов функции pthread_sleepon_wait(). Вот второй while-цикл:
while (!data_ready) {
pthread_sleepon_wait(&data_ready);
}
Функция pthread_sleepon_wait() в действительности выполняет три действия:
1. Разблокирует мутекс библиотеки ждущих блокировок.
2. Выполняет собственно операцию ожидания.
3. Снова блокирует мутекс библиотеки ждущих блокировок.
Причина обязательной разблокировки/блокировки мутекса библиотеки проста: поскольку суть мутекса состоит в обеспечении взаимного исключения доступа к флагу data_ready, мы хотим запретить потоку-«производителю» изменять флаг data_ready, пока мы его проверяем. Но если мы не разблокируем флаг впоследствии, то поток-«производитель» не сможет его установить, чтобы сообщить нам о доступности данных! Операция повторной блокировки выполняется автоматически исключительно для удобства, чтобы вызвавший функцию pthread_sleepon_wait() поток не беспокоился о состоянии блокировки после «пробуждения».
Давайте перейдем теперь к потоку-«производителю» и рассмотрим, как он использует библиотеку ждущих блокировок. Вот его полная реализация:
producer() {
while (1) {
// Ждать прерывания от оборудования...
pthread_sleepon_lock();
data_ready = 1;
pthread_sleepon_signal(&data_ready);
pthread_sleepon_unlock();
}
}
Как вы видите, поток-«производитель» также блокирует мутекс, чтобы получить монопольный доступ к флагу data_ready перед его установкой.
Клиента «пробуждает» не установка флага data_ready в единицу (1), а вызов функции pthread_sleepon_signal()!
Давайте рассмотрим происходящее в подробностях. Определим состояния «потребителя» и «производителя» следующим образом:
| Состояние | Означает |
|---|---|
| CONDVAR | ожидание соответствующей ждущей блокировке условной переменной |
| MUTEX | ожидание мутекса |
| READY | состояние готовности, т.е., готов выполняться или уже выполняется |
| INTERRUPT | ожидание прерывания от аппаратных средств |
| Действие | Владелец мутекса | Состояние «потребителя» | Состояние «производителя» |
|---|---|---|---|
| «потребитель» блокирует мутекс | «потребитель» | READY | INTERRUPT |
| «потребитель» проверяет флаг data_ready | «потребитель» | READY | INTERRUPT |
| потребитель вызывает функцию pthread_sleepon_wait() | «потребитель» | READY | INTERRUPT |
| функция pthread_sleepon_wait() разблокирует мутекс | мутекс свободен | READY | INTERRUPT |
| функция pthread_sleepon_wait() блокируется | мутекс свободен | CONDVAR | INTERRUPT |
| пауза до прерывания | мутекс свободен | CONDVAR | INTERRUPT |
| аппаратные средства генерируют данные | мутекс свободен | CONDVAR | READY |
| «производитель» блокирует мутекс | «производитель» | CONDVAR | READY |
| «производитель» устанавливает флаг data_ready | «производитель» | CONDVAR | READY |
| «производитель» вызывает pthread_sleepon_signal() | «производитель» | CONDVAR | READY |
| «потребитель» «пробуждается», функция pthread_sleepon_wait() пытается заблокировать мутекс | «производитель» | MUTEX | READY |
| «производитель» разблокирует мутекс | мутекс свободен | MUTEX | READY |
| «потребитель» получает мутекс | «потребитель» | READY | READY |
| «потребитель» обрабатывает данные | «потребитель» | READY | READY |
| «производитель» ждет новых данных от аппаратуры | «потребитель» | READY | INTERRUPT |
| пауза («потребитель» обрабатывает полученные данные) | «потребитель» | READY | INTERRUPT |
| «потребитель» завершает обработку и разблокирует мутекс | мутекс свободен | READY | INTERRUPT |
| «потребитель» возвращается в начало цикла и блокирует мутекс | «потребитель» | READY | INTERRUPT |