Это, вероятно, остаток от дней, когда вы могли бы оправдать первый выпуск более широкой блокировки (в данном случае serviceQueue), если это не влияет на правильность, потому что другой поток может сразу же начать приобретать его, пока вы освобождаете больше узкий замок.
Представьте, что каждый приобретатель или выпуск занимает 1 единицу времени, а другая операция занимает 0 единиц времени. Читатель просто увеличил счетчик считывателей в момент времени 0, и в очереди очереди обслуживания появился следующий читатель.
Если readCountAccess не выпущен первый и второй serviceQueue, следующий читатель может приобрести serviceQueue мьютекс не ранее, чем во время 3. Поэтому самое раннее это может быть сделано с церемонии регистрации блокировка чтения во время 6. выигравшей стороной здесь будут другие читатели, ожидающие выхода, и они менее важны, потому что они не должны также выпускать resourceAccess (потому что наш оригинальный читатель только что зарегистрировался как таковой).
Если с другой стороны serviceQueue выпущен первый и второй readCountAccess, следующий читатель может приобрести serviceQueue мьютекс уже во время 2. Это означает, что это может быть сделано с замком церемонии регистрации чтения уже на время 5.
Я до сих пор предпочитаю, чтобы разблокировать с помощью симметричной схемы, хотя - она менее подвержены ошибкам, она имеет более широкое признание, и бремя доказывания того, что в настоящее время это хуже в любом случае, чем версия выше будет лежать на плечах сомневающихся.