[concurrency-interest] ReentrantReadWriteLock should throw ex on writeLock().lock() if read lock held?
jed at atlassian.com
Wed Sep 6 21:32:02 EDT 2006
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
> I naïvely used it :-) , but as a general discussion point. If some
> 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.
More information about the Concurrency-interest