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

Jed Wesley-Smith jed at atlassian.com
Wed Sep 6 21:32:02 EDT 2006

Thanks Tim,

If lock detection is expensive in the uncontended path then this is an 
entirely sensible explanation.

I would still suggest the docs be clarified though.

Tim Peierls wrote:
> On 9/5/06, *Jed Wesley-Smith* <jed at atlassian.com 
> <mailto: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.
- jed.

More information about the Concurrency-interest mailing list