DimsНе пойму, какова идеология работы класса ReentrantReadWriteLock? У него есть два лока, для чтения и для записи. Кто может захватить лок и в каких случаях? Например, если какой-то поток держит лок чтения, то может ли другой поток захватить лок записи?

Если другой поток держит лок чтения, то мы ждем, пока эта операция завершится, а т.к. внутри при этом обновляется счетчик запросов на запись. то после выхода из чтения лок будет захвачен записыващим потоком, а читатели будут ждать.
Но ввиду того, что RW предназначен для сценария, когда записывающих потоков мало, то ожиданием завершения операция чтения можно пренебречь.
DimsЕсли "нет", тогда получается, что никакого преимущества два лока не дают, потому что записывающий поток всё равно ждёт, пока читающих освободит ресурс. То же самое было бы и с одним общим локом.
RW лок ничем не лучше "толстого" лока в ситуациях, когда число записывающих тредов велико, но он для таких ситуаций не предназначен.
DimsА если "да", тогда получается, что читающий поток может выполнять чтение параллельно с тем, как записывающий поток выполняет запись. И почему это не приводит к гонке данных?

Читающий поток не может вообще никак читать параллельно записывающему т.к. это нарушает контракт RW лока в котором сказано, что читатели ждут писателей.

Нет. Чтобы захватить write-lock нужно будет дождаться того, чтобы поток, который сейчас захватил read-lock, его освободит.
И не важно сколько у вас читателей т.к. когда есть запросы на запись, то читатели ждут их завершения.