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

David Holmes dcholmes at optusnet.com.au
Tue Sep 5 20:11:14 EDT 2006


I guess the documentation could clarify what "not possible" means.

Cheers,
David
  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Jed
Wesley-Smith
  Sent: Wednesday, 6 September 2006 10:02 AM
  To: concurrency-interest at cs.oswego.edu
  Subject: Re: [concurrency-interest] ReentrantReadWriteLock should throw ex
on writeLock().lock() if read lock held?


  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/f6cad4b8/attachment.html 


More information about the Concurrency-interest mailing list