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

Jed Wesley-Smith jed at atlassian.com
Tue Sep 5 20:02:23 EDT 2006


Hi David,

Thanks for the reply.

David Holmes wrote:
> Hi Jed,
>   
>> Just a quick question regarding the acquisition policy of the
>> ReentrantReadWriteLock if a reader tries to grab the write lock. What
>> currently happens is that the call to writeLock().lock() blocks forever.
>> Wouldn't it be better to throw some sort of exception like
>> IllegalMonitorStateException (not that one specifically, but something
>> like it)?. That way you would fail-fast and find the problem fairly
>> quickly...
>>     
>
> "better" is subjective. Correctly written code simply won't do this. If a
> check were put in for this then correctly written code would pay the price
> on the every writeLock acquisition.
>
> You can easily write your own wrapper that would add such a check via an
> assert; or place the assert directly in your code.
>   
These are definitely solutions. My only point is that the client of the 
class needs to be aware of this behaviour of the class in order to be 
correct. The documentation of the ReentrantReadWriteLock class says 
clearly that upgrading of a read lock to a write lock is _not_ possible, 
but the behaviour in that use-case is not specified and quite frankly 
surprising.

Personally as a client of the class I would prefer it to either (a) 
throw an exception (preferred) or (b) document that the attempt will 
block forever.

-- 
cheers,
- jed.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060906/497748c3/attachment.html 


More information about the Concurrency-interest mailing list