Интерфейс ReadWriteLock

public interface ReadWriteLock

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

Все реализации ReadWriteLock должны гарантировать, что эффекты синхронизации памяти от операций writeLock (как указано в интерфейсе Lock) также распространяются на связанную readLock. Иными словами, поток, успешно получивший блокировку чтения, увидит все изменения, внесённые до предыдущего освобождения блокировки записи.

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

Повысит ли блокировка чтения-записи производительность по сравнению с блокировкой взаимного исключения, зависит от частоты чтения данных относительно частоты их изменения, продолжительности операций чтения и записи, а также от конкуренции за доступ к данным — то есть от количества потоков, которые пытаются одновременно читать или записывать данные. Например, коллекция, изначально заполненная данными и впоследствии редко изменяемая, но часто используемая для поиска (например, некоторый каталог), идеально подходит для применения блокировки чтения-записи. Однако если обновления становятся частыми, данные большую часть времени находятся под эксклюзивной блокировкой, и параллелизм практически не повышается. Кроме того, если операции чтения слишком короткие, накладные расходы реализации блокировки чтения-записи (которая по своей природе сложнее блокировки взаимного исключения) могут превышать затраты на выполнение, особенно поскольку многие реализации блокировки чтения-записи по-прежнему сериализуют все потоки в небольшом участке кода. В конечном счёте определить, подходит ли блокировка чтения-записи для вашего приложения, помогут только профилирование и измерения.

Хотя базовые операции блокировки чтения-записи просты, реализация должна принимать множество решений о политике работы, которые могут повлиять на эффективность блокировки чтения-записи в конкретном приложении. Например:

• Решение о том, кому предоставить блокировку — чтения или записи, — если ожидают и читатели, и писатели, когда писатель освобождает блокировку записи. Распространена политика предпочтения писателей, поскольку предполагается, что операции записи короткие и редкие. Предпочтение читателей встречается реже, так как при частых и длительных операциях чтения оно может привести к значительным задержкам записи. Возможны также справедливые реализации, предоставляющие блокировки «по очереди».
• Решение о том, предоставлять ли блокировку чтения потокам, запрашивающим её, когда читатель уже активен, а писатель ожидает. Предпочтение читателей может бесконечно задерживать писателя, а предпочтение писателя может снижать потенциальный параллелизм.
• Решение о том, являются ли блокировки реентерабельными: может ли поток, удерживающий блокировку записи, повторно получить её? Может ли он получить блокировку чтения, удерживая блокировку записи? Является ли сама блокировка чтения реентерабельной?
• Можно ли понизить блокировку записи до блокировки чтения, не позволяя промежуточному писателю получить блокировку? Можно ли повысить блокировку чтения до блокировки записи с приоритетом перед другими ожидающими читателями или писателями?

При оценке пригодности конкретной реализации для вашего приложения следует учитывать все эти факторы.