Краткий ответ

RwLock<T> может проиграть Mutex<T>, если критические секции короткие, конкуренция невелика или чтение выполняется почти последовательно. Параллельный доступ нескольких читателей не бесплатен: RwLock поддерживает счётчик читателей, координирует писателей и выполняет дополнительную синхронизацию. Поэтому выбирать его следует по профилю нагрузки, а не только по доле операций чтения.

Исторический контекст

Обычный Mutex разрешает владеть защищёнными данными только одному потоку. RwLock появился для сценариев, где чтения значительно чаще записей: несколько потоков могут одновременно держать блокировку чтения, но запись требует исключительного доступа.

Такой подход уменьшает ожидание читателей при действительно параллельной нагрузке. Однако дополнительный режим блокировки усложняет внутренний протокол и не гарантирует автоматического выигрыша по производительности.

Постановка проблемы

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

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

Подробное решение

Mutex подходит, когда критическая секция короткая и простая, а конкуренция между потоками умеренная. Его состояние обычно проще: поток пытается получить единственное владение, выполняет операцию и освобождает блокировку.

RwLock должен различать два состояния доступа. Читатель увеличивает число активных читателей, а писатель ждёт, пока не завершатся все читатели, после чего блокирует новые входы. Эти операции требуют синхронизации и могут вызывать дополнительный обмен данными между кэшами процессоров.

При высокой конкуренции читателей RwLock может выиграть, потому что читатели не выстраиваются в единую очередь. Но выигрыш появляется только тогда, когда чтения достаточно долгие или действительно выполняются параллельно. Для коротких операций расходы на управление блокировкой могут доминировать.

Наличие писателей также меняет картину. Политика предоставления приоритета писателям зависит от реализации; для std::sync::RwLock полагаться на конкретную политику справедливости нельзя. Частые записи или постоянный поток новых читателей могут увеличивать задержки противоположной стороны.

Нужно учитывать и размер защищаемых данных. Если под блокировкой выполняется дорогое копирование, сортировка или обращение к медленной системе, выбор между Mutex и RwLock становится менее важным, чем сокращение критической секции. Часто эффективнее скопировать небольшой снимок данных под блокировкой и продолжить вычисления уже после её освобождения.

Пример такого разделения:

use std::sync::{Arc, RwLock};

fn read_snapshot(state: &Arc<RwLock<Vec<u32>>>) -> Vec<u32> {
    let snapshot = state.read().unwrap().clone();
    snapshot.into_iter().map(|x| x * 2).collect()
}

Блокировка удерживается только во время копирования. Но копирование большого объекта само по себе может быть дорогим, поэтому в реальной системе следует измерять задержки, пропускную способность и распределение времени ожидания.

Для асинхронного кода нужно отдельно выбирать примитив: синхронный std::sync::RwLock нельзя бездумно удерживать через точку await, поскольку заблокированный поток runtime может остановить другие задачи. Это уже вопрос совместимости блокировки с моделью выполнения, а не доказательство того, что RwLock быстрее или медленнее Mutex.

Ситуация из практики

В HTTP-сервисе несколько потоков читают небольшой конфигурационный флаг, а запись выполняется редко. Вариант с RwLock кажется естественным: разрешить одновременные чтения. Однако измерения показывают, что чтения очень короткие, а число рабочих потоков невелико; координация счётчика читателей становится заметной частью времени запроса.

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

Второй вариант — заменить его на Mutex. Он проще и иногда быстрее на коротких критических секциях, но все читатели будут последовательно конкурировать за одну блокировку.

Третий вариант — использовать атомарный тип для простого флага или счётчика. Это устраняет блокировку, но применимо только при подходящей модели данных и требуемой атомарности операции.

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

Что кандидаты часто упускают

1. Достаточно ли того, что чтений больше, чем записей, чтобы выбрать RwLock?

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

2. Гарантирует ли RwLock, что писатель обязательно получит доступ после появления в очереди?

Нельзя переносить такую гарантию между реализациями. Политика справедливости и приоритета зависит от конкретного типа и платформы; для стандартного std::sync::RwLock приложение не должно рассчитывать на определённый порядок выдачи блокировки. Если важны строгие свойства справедливости или предсказуемые задержки, их нужно проверять в документации выбранной реализации и на целевой платформе.

3. Можно ли заменить RwLock на атомарную переменную без изменения семантики?

Не всегда. Атомарная переменная хорошо подходит для отдельных значений с простыми операциями, но не заменяет составную транзакцию над несколькими полями. Если нужно согласованно изменить несколько связанных значений или поддержать сложный инвариант, потребуется блокировка либо более специализированная lock-free конструкция с тщательно выбранными порядками памяти.