Thread-safe interface, Потокобезопасный интерфейс Опции

[Andrew Selivanov]

Хотелось бы рассмотреть тему потокобезопасных интерфейсов, подробно описанную в http://www.cs.wustl.edu/~schmidt/PDF/locking-patterns.pdf

Проблема:
Допустим мы имеем некоторый класс (интерфейс) и несколько функций внутри. Внутри каждой функции мы захватываем мутекс. Теперь, если мы вызовем одну такую функцию из другой, налицо будет deadlock.

Решение:
Разделить каждую функцию на две - первая будет открытой, вторая закрытой. Открытая функция будет захватывать мутекс и вызывать закрытую (в которой и будет находится основная логика).

[archimed7592]

Решение №2: использовать рекурсивный мьютекс.

[ViGOur]

Решение №2: использовать рекурсивный мьютекс.

Это что за зверек?

[Andrew Selivanov]

Решение №2: использовать рекурсивный мьютекс.

Действительно, однако (цитата из бумаги первого поста) "...Moreover, even if this File Cache implementation is strategized with a recursive mutex it will incur unnecessary overhead when it reacquires the mutex in bind."
Хотя IMHO перерасход будет совсем небольшим...

[archimed7592]

Это что за зверек?

При повторной попытке блокирования тем же потоком он не блокируется, а просто увеличивается счётчик. При разблокировании уменьшается. Если счётчик равен нулю мьютекс свободен для блокировки любым потоком.

однако (цитата из бумаги первого поста)

Каюсь, бумагу не читал, но, IIRC, стандартный виндовый мьютекс изначально рекурсивный. В бусте есть рекурсивный мьютекс. Вообще говоря, не вижу, в чём будет заключатся оверхэд(увеличивание счётчика?).

[Serik]

Проблема:
Допустим мы имеем некоторый класс (интерфейс) и несколько функций внутри. Внутри каждой функции мы захватываем мутекс. Теперь, если мы вызовем одну такую функцию из другой, налицо будет deadlock.

Я делаю просто еще один параметр у методов, и явно указываю, нужно блокировать мутекс или нет.