ReentrantReadWriteLock should throw ex on writeLock().lock() if read lock held?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

ReentrantReadWriteLock should throw ex on writeLock().lock() if read lock held?

Jed Wesley-Smith
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...

Or in other words, is there a specific reason you would want to call
something in such a way that the only return possible is an
InterruptedException if you are lucky enough that another thread notices
your plight and interrupts you :-)

--
cheers,
- jed.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ReentrantReadWriteLock should throw ex on writeLock().lock() if read lock held?

Giuliano Mega
Hi Jed,

I always thought that Lock.tryLock was supposed to play this role
(except that it returns false instead of throwing an exception). Am I
missing something from your problem that prevents you from using
tryLock?

Best,

On 9/5/06, Jed Wesley-Smith <[hidden email]> wrote:

> 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...
>
> Or in other words, is there a specific reason you would want to call
> something in such a way that the only return possible is an
> InterruptedException if you are lucky enough that another thread notices
> your plight and interrupts you :-)
>
> --
> cheers,
> - jed.
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>


--
Giuliano Mega <[hidden email]>
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ReentrantReadWriteLock should throw ex on writeLock().lock() if read lock held?

David Holmes-3
In reply to this post by Jed Wesley-Smith
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.

Cheers,
David Holmes

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ReentrantReadWriteLock should throw ex on writeLock().lock() if read lock held?

Jed Wesley-Smith
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.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ReentrantReadWriteLock should throw ex on writeLock().lock() if read lock held?

David Holmes-3
I guess the documentation could clarify what "not possible" means.
 
Cheers,
David
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]On Behalf Of Jed Wesley-Smith
Sent: Wednesday, 6 September 2006 10:02 AM
To: [hidden email]
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.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ReentrantReadWriteLock should throw ex on writeLock().lock() if read lock held?

Jed Wesley-Smith
In reply to this post by Giuliano Mega
Hi Giuliano,

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.

Giuliano Mega wrote:

> Hi Jed,
>
> I always thought that Lock.tryLock was supposed to play this role
> (except that it returns false instead of throwing an exception). Am I
> missing something from your problem that prevents you from using
> tryLock?
>
> Best,
>
> On 9/5/06, Jed Wesley-Smith <[hidden email]> wrote:
>  
>> 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...
>>
>> Or in other words, is there a specific reason you would want to call
>> something in such a way that the only return possible is an
>> InterruptedException if you are lucky enough that another thread notices
>> your plight and interrupts you :-)
>>    
--
cheers,
- jed.


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ReentrantReadWriteLock should throw ex on writeLock().lock() if read lock held?

tpeierls
On 9/5/06, Jed Wesley-Smith <[hidden email]> 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


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ReentrantReadWriteLock should throw ex on writeLock().lock() if read lock held?

Jed Wesley-Smith
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* <[hidden email]
> <mailto:[hidden email]>> 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.
--
cheers,
- jed.


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest