[concurrency-interest] AtomicReference weakCompareAndSet "Mayfailspuriously"?

Doug Lea dl at cs.oswego.edu
Wed May 17 10:55:36 EDT 2006


Thomas Hawtin wrote:
> Doug Lea wrote:
>>
>> A plain compareAndSet has volatile-write memory model semantics, while a
>> weakCompareAndSet has non-volatile-write memory model semantics.
> 
> And the same for (non-)volatile-read memory model semantics, if my 
> reading of the package JavaDocs is correct.
> 
> Is there any particular reason for not having a "weakGet" method? Going 
> back to Hanson Char's example:
> 
>  int maxLatencySnapshot = this.maxLatency.get();
>  if (latency > maxLatencySnapshot) {
>    if (this.maxLatency.weakCompareAndSet(maxLatencySnapshot, latency)) {
> 
> Most of the gains that may be made from using weakCompareAndSet seem to 
> be blown away by the get. (Sun's implementation doesn't seem to 
> differentiate between weakCompareAndSet and compareAndSet, at the moment.)
> 

Generally, volatile-reads are cheap -- the main cost
is suppressing optimizations/reorderings. On most machines,
they don't generate machine-level barriers, and
on the ones where they do (mainly: Itanium/IA64), they are the
cheapest kind, and so barely measurable.

And the suppressed optimizations/orderings are exactly those you'd need to
suppress in uses like this. Without this, a VM might (depending on
context) forever cache a single read of the value, which would rarely
be useful for an AtomicX. There may be a few use-cases for some kind of
weakGet, but I think they are most rare.

-Doug


More information about the Concurrency-interest mailing list