[concurrency-interest] ReadWriteLock implementation with extendedpolicy providing upgradeable read-locks?

David Holmes dcholmes at optusnet.com.au
Fri Nov 10 20:34:15 EST 2006

Hello Oliver,

I think this makes the third request for such functionality since 2000 -
hence it hasn't been a high priority :)

Intention-locks were discussed by the EG a couple of times but basically
they didn't meet the acceptance criteria. They are quite complicated to
implement correctly, have ugly API's and don't inter-mix with normal
ReadWriteLocks. They are also rarely needed oustide transactional contexts.
But maybe it is time to consider them again for Java 7.

That said, with changes that went in to Java 6 to track read-lock ownership,
it shouldn't be too hard for you to modify ReentrantReadWriteLock to allow
the final-reader to acquire the writeLock. That isn't quite an
intention-lock but might satisfy your needs.

Can you describe the use-case for this.

David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Oliver
> Pfeiffer
> Sent: Friday, 10 November 2006 9:57 PM
> To: concurrency-interest at cs.oswego.edu
> Subject: [concurrency-interest] ReadWriteLock implementation with
> extendedpolicy providing upgradeable read-locks?
> I'm looking for a certain ReadWriteLock implementation following a very
> similar policy as Doug Leas ReentrantReadWriteLock except that the last
> reader is enabled to be upgraded to a writer. The lack of these concept in
> default JDK15 distribution is the source of most threading issues
> I have had
> to fix in the last months in foreign code.
> Unfortunately it's obvious that this can't be solved by the common
> read-write-lock concept as provided by the interface, since two
> simultaneous
> threads, each holding the read-lock, may both acquire the write-lock and
> therefore will consequently deadlock each other. This seems to be solvable
> only by classifying read-locks as exlusive-read-locks and
> non-exclusive-read-locks. The exclusive-read-lock is a normal read-lock
> except that it can only be shared with other non-exclusive-read-locks (but
> not with other exclusive-read-locks or write-locks). In other words: there
> can be only one thread holding the exclusive-read-lock per time thus this
> exclusice-read-lock can be safely upgraded to a write-lock
> without any risc
> of deadlocking. Certainly any non-exclusive-read-lock acquiring the
> write-lock or the exclusive-read-lock will block foreever, but an
> exclusive-read-lock can always acquire the non-exclusive-read-lock and the
> write-lock.
> The benefit of such a concept is the ability to share many readers with a
> single reader that _might_ be need to lazily become a writer. Or
> in general
> there is no need to exclusively lock a model when there are time-consuming
> preparations needed before a write-lock is actually acquired. This can
> result in a performance gain bundeled with a less risc of deadlocking.
> Does anybody knows a serious extension of default java
> concurrency features
> providing such a concept?
> --
> Grüße - Regards
> Oliver Pfeiffer
> ICQ-ID 84320006
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list