TL; DR - не сработает.
Как указывает @Radiodef, вы не сможете реализовать ReadWriteLock API. Такие методы, как getOwner, getQueuedThreads и т. Д., Не могут быть реализованы, если состояние блокировки - всего один AtomicInteger.
Полный возврат был бы невозможен. Для повторного входа обычно требуется, чтобы вы закодировали идентификаторы потоков, в настоящее время удерживающих блокировку, и количество повторных входов для каждого из них. Для читателей мы могли бы использовать один счет (и не идентифицировать), но одному писателю нужны и идентификатор, и счет. Подсчет количества и идентификатора потока в 32-битное целое число, вероятно, не сработает. (A Thread предлагает числовой атрибут id, который является уникальным и неизменным для времени жизни потока ... но id является long.)
Если вы используете только один AtomicInteger в качестве состояния блокировки, вы не можете парковать поток, ожидающий ожидаемой блокировки. (Для парковки, чтобы работать, поток, который снимает блокировку, должен знать, какой поток нужно распаковать. Но вы не можете это представить.) Это означает, что вам нужно будет использовать спин-блокировку 1 , которая стоит дорого и не масштабируемая.
Таким образом, вы не можете реализовать API ReadWriteLock или семантику полного повторного входа. Если вы удалите эти требования, вы могли бы возможно реализовать простые блокировки чтения-записи (реентерабельные для читателей, реентерабельные для писателей), но вам нужно было бы сделать спин-блокировку.
1 - При спин-блокировке поток, ожидающий условной блокировки, «вращается», выполняя цикл занятости, пока блокировка не станет доступной. Это нормально для блокировок, когда конкуренция маловероятна и недолговечна ... или когда ядро больше ничего не может сделать. Но это слишком неэффективно для нормального использования.