[concurrency-interest] ReentrantReadWriteLock should throw ex on writeLock().lock() if read lock held?

Tim Peierls tim at peierls.net
Wed Sep 6 10:30:23 EDT 2006


On 9/5/06, Jed Wesley-Smith <jed at atlassian.com> wrote:
>
> tryLock() does the job, and I don't have a problem using it. I don't
> bring this up as a particular problem I have (apart from the first time
> I naïvely used it :-) , but as a general discussion point. If some code
> does call writeLock().lock() while holding a read lock it will block
> forever - which seems to me undesirable.


Yes, it is undesirable. It is essential to encapsulate access to the RWL to
ensure that client code cannot get the program into such undesirable states.

There are sharp edges in java.util.concurrent.locks. These are low-level
tools; JCiP treats them as an advanced topic. It wouldn't be right to add
expensive runtime checks to protect developers who fail to encapsulate their
use of these tools.

--tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060906/43c65f34/attachment-0001.html 


More information about the Concurrency-interest mailing list