[concurrency-interest] AQS Question (WAS: Need a special lockimplementation)
dcholmes at optusnet.com.au
Thu Aug 16 19:57:19 EDT 2007
I don't see any issue with encoding auxiliary state this way.
> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Oliver
> Sent: Friday, 17 August 2007 9:26 AM
> To: concurrency-interest at cs.oswego.edu
> Subject: [concurrency-interest] AQS Question (WAS: Need a special
> I have finally come up with a solution based on AQS:
> However, I had more state than would fit into an integer, so I
> introduced more state (in form of a Set of reader threads).
> Now my question: What is the right way to handle this mixed state? I
> tried to code, NO_LOCK, A_SINGLE_READ_LOCK, MORE_READ_LOCKS and
> WRITE_LOCK into the state and added more details in form of the set of
> reader threads for states A_SINGLE_READ_LOCK and MORE_READ_LOCKS. Does
> that make sense? It looks really strange.
> In case anyone minds, here is the code. Look for the inner class "Sync".
> Thanks for any hints in advance and cheers
> 2007/8/15, Oliver Zeigermann <oliver at zeigermann.de>:
> > Hi folks!
> > I need a lock implementation having the following features:
> > (1) read/write lock
> > (2) ownership must be transferable from one thread to another
> > (3) upgrade from read-lock to write-lock must be supported (I know
> > this is deadlock prone)
> > (4) one must be able to find out which thread holds which locks
> > The lock is intended to protect resources that exist in large numer.
> > Does anyone know of an implementation that has those features or at
> > least something I could use as a starting point? Should I use AQS and
> > start from scratch?
> > Thanks in advance and cheers
> > Oliver
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest