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

Tim Peierls tim at peierls.net
Fri Nov 10 07:13:42 EST 2006


You should consider using AbstractQueuedSynchronizer to build the kind of
lock you describe:

http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/AbstractQueuedSynchronizer.html

Also see Section 14.5 of Java Concurrency in Practice.

I have some examples of other non-standard lock implementations using AQS,
if you're interested.

--tim

On 11/10/06, Oliver Pfeiffer <pfeiffer at tzi.de> wrote:
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20061110/58eee591/attachment.html 


More information about the Concurrency-interest mailing list