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

Oliver Pfeiffer pfeiffer at tzi.de
Thu Nov 16 17:03:02 EST 2006


Hello David,

our use-case for an intention lock is the common "prepare for write"
operation. Our application model contains a complex time-based interval
storage for telemetry data. This storage is accessed concurrently by many
readers (acquiring old telemetry) and many writers (providing new
telemetry). Each writer must only provide data that doesn't already exist in
the model, thus the writer must only submit the delta to the model. The
submission itself is a very fast operation, but the delta creation (by
intersecting thousands of intervals) takes much longer. Since the model
isn't changed by the delta creation, there is no reason to exclude other
readers - only the other writers must be blocked. Using an intention lock
would provide a significant performance boost for this use-case.

-- 
Grüße - Regards
Oliver Pfeiffer
ICQ-ID 84320006 

> -----Original Message-----
> From: David Holmes [mailto:dcholmes at optusnet.com.au] 
> Sent: Saturday, November 11, 2006 2:34 AM
> To: Oliver Pfeiffer; concurrency-interest at cs.oswego.edu
> Subject: RE: [concurrency-interest] ReadWriteLock 
> implementation with extendedpolicy providing upgradeable read-locks?
> 
> 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.
> 
> Cheers,
> 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