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

Peter Veentjer - Anchor Men p.veentjer at anchormen.nl
Tue Aug 23 16:52:06 EDT 2005

Your version doesn't take advantage of the volatility of _item. 
What is there to take advantage of (I guess I`m missing something)? 
And I would rather make something that is less efficient but a lot clearer.
 So if mine doesn`t work.. I`ll change it, but if it does, I won`t change it 
(it would be to difficult to understand).

Also, do you have any experimental evidence to suggest that the Lock will ever
need to be fair? It seems unlikely to me, especially if you add the volatile
optimization above, where readers don't even block when there's a non-null value.

And since there won't be much blocking, there won't be much lock contention,
so you don't really need to use ReentrantLock at all. Stick with intrinsic
locking, as in the SimpleAwaitableValue code I posted.

ReentrantLock is appropriate when you need a feature that it provides that
intrinsic locking doesn't or when you expect a *lot* of contention. Otherwise,
intrinsic locking is easier to read and likely to perform just as well, if not
You have lost me here. I`m not a concurrency master, so I would rather have something
that I understand and works... than something that maybe works better/efficient but I can`t 

Using RWL doesn't prevent two readers from seeing different values if there is
an intervening write, so I don't think you need it.
With a RWL this behaviour can be realised. If every readed returns the read value (so unlocks a readlock)
only a write lock can be optained of all readers have unlocked.


More information about the Concurrency-interest mailing list