AW: [concurrency-interest] Waiting for object value to be available.

Doug Lea dl at
Tue Aug 23 14:43:40 EDT 2005

Ernst, Matthias wrote:
> Tim's SimpleAvaitableValue does it, yet I was hoping to find a simple
> lock-free version that avoids "lock-getValue-unlock"-sequence in the
> common case (value != null) and requires only a volatile read.

(Not sure I understand. Tim's does that bypass, at the expense only
of a recheck, which is likely to be about as fast as anything else.)

> So I thought, "AbstractQueuedSynchronizer implements all the queueing,
> you just have to model the state transitions", and tried to morph AQS by
> changing the state type from 'int' to 'Object'.

I can't think of a really good reason to want to do this. Why not use
integer codes for null/nonull and then another Object field for data?
Like Tim though, my guess is that even this is excessive compared to
Tim's version unless it is a performance bottleneck.

> This proved more complicated than I had expected :-)
> Is this a case for separating the queueing functionality from the
> integer state and the notion of shared/exclusive?

Among the challenges in doing this would be to give some handle to
synchronizer implementors for avoiding garbage retention stemming
from references inside AQS nodes. Lack of good ideas about this
and related issues led us to add "Long" version of AQS to Mustang
but not "Reference" version.


More information about the Concurrency-interest mailing list