Что такое масштабируемый замок?

Question

Что такое масштабируемый замок? И как он отличается от немасштабируемой блокировки? Я впервые увидел этот термин в контексте rw-lock TBB и не мог решить, что использовать.

Кроме того, существует ли какой-либо rw-lock, который определяет приоритеты читателей над писателями?

Answer 1

Не существует формального определения термина «масштабируемый замок» или «немасштабируемый замок». Это подразумевает, что некоторые алгоритмы блокировки, методы или реализации выполняются достаточно хорошо, даже когда есть много споров для блокировки, а некоторые нет.

Иногда проблема является алгоритмической. Например, наивная реализация приоритетного наследования может потребовать от O (n) работы по освобождению блокировки, где n - количество ожидающих потоков. Это означает, что O (n^2) работает для каждого ожидающего потока, который будет обслуживаться.

Иногда проблема связана с оборудованием. Простые блокировки (например, реализации, для которых линия кэша блокировки совместно используется, а эквайеры не отступают) не масштабируются на аппаратном уровне SMP с одним межсоединением шины, потому что для записи в строку кэша требуется, чтобы CPU обретал линию кэша, и межсоединение CPU является одной точкой раздора. Если есть n процессоров, пытающихся одновременно получить одну и ту же блокировку, вы можете получить трафик O (n) для получения блокировки. Опять же, это означает, что O (n^2) время для всех n CPU удовлетворяется.

В общем, вы должны избегать не масштабируемых замки, если два условия не будут выполнены:

1. Разногласия свет.
2. Критический участок очень короткий.

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

Что касается вашего последнего вопроса, я не знаю о готовой блокировке чтения-записи, которая благоприятствует читателям. На самом деле, большинство API не определяют политику, включая pthreads (досадно).

Мой первый комментарий: вы, вероятно, этого не хотите. Если у вас есть высокая конкуренция, предпочтение одному над другим убивает пропускную способность, и если у вас нет высокого мнения, это не изменит ситуацию. Единственная причина, по которой я могу думать, что не использовать rw-блокировку с вполне справедливой политикой, - это если у вас есть приоритеты потоков, которые должны соблюдаться, поэтому вы хотите, чтобы поток с наивысшим приоритетом был предпочтительнее.

Но если вам нужно, вы всегда можете катиться самостоятельно. Все, что вам нужно, это пара флагов (одна для «читателей может идти сейчас», а другая для «писателя может идти сейчас»), переменные состояния, защищающие флаги, один мьютекс, защищающий переменные условия, и пару счетчиков, указывающих, как многие читатели и писатели ждут. Это должно быть все, что вам нужно; осуществление этого должно быть весьма поучительным.