Энтони Уильямс - Параллельное программирование на С++ в действии. Практика разработки многопоточных программ

Функция try_lock()работает так же, как lock(), с одним отличием — если вызов try_lock()для internal_mutexзавершается ошибкой (7), то мы не владеем мьютексом и, следовательно, не изменяем уровень иерархии, а вместо trueвозвращаем false.

Все проверки производятся на этапе выполнения, но, по крайней мере, они не зависят от времени — нет нужды дожидаться, пока сложатся редкие условия, при которых возникает взаимоблокировка. Кроме того, ход мыслей проектировщика, направленный на подобное отделение логики приложения от мьютексов, помогает предотвратить многие возможные причины взаимоблокировок еще до того, как они прокрадутся в код. Такое мысленное упражнение полезно проделать даже в том случае, когда проектировщик не собирается фактически кодировать проверки во время выполнения.

Я уже упоминал в начале этого раздела, что взаимоблокировка может возникать не только вследствие захвата мьютекса, а вообще в любой конструкции синхронизации, сопровождающейся циклом ожидания. Поэтому стоит обобщить приведенные выше рекомендации и на такие случаи. Например, мы говорили, что следует по возможности избегать вложенных блокировок, и точно так же не рекомендуется ждать поток, удерживая мьютекс, потому что этому потоку может потребоваться тот же самый мьютекс для продолжения работы. Аналогично, если вы собираетесь ждать завершения потока, то будет разумно определить иерархию потоков, так чтобы любой поток мог ждать только завершения потоков, находящихся ниже него в иерархии. Простой способ реализовать эту идею — сделать так, чтобы присоединение потоков происходило в той же функции, которая их запускала (как описано в разделах 3.1.2 и 3.3).

Функция std::lock()и шаблон класса std::lock_guardпокрывают большую часть простых случаев блокировки, по иногда этого недостаточно. Поэтому в стандартную библиотеку включен также шаблон std::unique_lock. Подобно std::lock_guard, этот шаблон класса параметризован типом мьютекса и реализует такое же управление блокировками в духе RAII, что и std::lock_guard, однако обладает чуть большей гибкостью.

Шаблон std::unique_lockобладает большей гибкостью, чем std::lock_guard, потому что несколько ослабляет инварианты — экземпляр std::unique_lockне обязан владеть ассоциированным с ним мьютексом. Прежде всего, в качестве второго аргумента конструктору можно передавать не только объект std::adopt_lock, заставляющий объект управлять захватом мьютекса, но и объект std::defer_lock, означающий, что в момент конструирования мьютекс не должен захватываться. Захватить его можно будет позже, вызвав функцию-член lock()объекта std::unique_lock(а не самого мьютекса) или передав функции std::lock()сам объект std::unique_lock. Код в листинге 3.6 можно было бы с тем же успехом написать, как показало в листинге 3.9, с применением std::unique_lockи std::defer_lock() (1)вместо std::lock_guardи std::adopt_lock. В новом варианте столько же строк, и он эквивалентен исходному во всем, кроме одной детали, — std::unique_lockпотребляет больше памяти и выполняется чуть дольше, чем std::lock_guard. Та гибкость, которую мы получаем, разрешая экземпляру std::unique_lock не владеть мьютексом, обходится не бесплатно — дополнительную информацию надо где-то хранить и обновлять.

Листинг 3.9.Применение std::lock()и std::unique_guardдля реализации операции обмена

class some_big_object;

void swap(some_big_object& lhs,some_big_object& rhs);

class X {

private:

some_big_object some_detail;

std::mutex m;

public:

X(some_big_object const& sd): some_detail(sd) {}

friend void swap(X& lhs, X& rhs) {

if (&lhs == &rhs) std::defer_lock оставляет

return; мьютексы не захваченными (1)

std::unique_lock lock_a(lhs.m, std::defer_lock);←┤

std::unique_lock lock_b(rhs.m, std::defer_lock);←┘

std::lock(lock_a, lock_b); ← (2) Мьютексы захватываются

swap(lhs.some_detail, rhs.some_detail);

}

};

В листинге 3.9 объекты std::unique_lockможно передавать функции std::lock() (2), потому что в классе std::unique_lockимеются функции-члены lock(), try_lock()и unlock(). Для выполнения реальной работы они вызывают одноименные функции контролируемого мьютекса, а сами только поднимают в экземпляре std::unique_lockфлаг, показывающий, что в данный момент этот экземпляр владеет мьютексом. Флаг необходим для того, чтобы деструктор знал, вызывать ли функцию unlock(). Если экземпляр действительно владеет мьютексом, то деструктор должен вызвать unlock(), в противном случае — не должен . Опросить состояние флага позволяет функция-член owns_lock().