[concurrency-interest] AtomicReferenceweakCompareAndSet "Mayfailspuriously"?

Brian Goetz brian at quiotix.com
Mon May 29 00:49:18 EDT 2006


> What Cliff wants is an atomic integer for use with counters that is not
> volatile, so that the extra memory barriers required for violatile semantics
> can be elided. This gives rise to a large performance boost in the context
> Cliff wants to use it - performance counters. Cliff can use weakCAS for this
> purpose.

The behavior Cliff wants is analogous to the meaning of volatile in the 
old memory model, where volatile wasn't required to ensure the 
visibility of any value other than the variable being written/read.

I think what bothers Bill about the proposal (I am confident Bill will 
correct me if I am wrong) is that there is no way to represent the old 
volatile semantics in the new memory model, and therefore there would be 
no mathematical basis for the proposed semantics of wCAS.

Stepping back, what Cliff really wants has nothing to do with wCAS, but 
for AtomicInteger.incrementAndGet to not be required to have any memory 
effects other than guaranteeing that it atomically updates the most 
up-to-date value of the AtomicInteger.  And the spec doesn't say 
anything about memory semantics of Atomic methods other than 
get/set/CAS, so this would be a consistent, though potentially 
confusing, implementation.

To summarize Cliff's argument, which is entirely motivated by practical 
considerations:

  - The specification of CAS currently requires a full fence.
  - Some processors support CAS operations that do not require full 
fences.
  - On these processors, CASing without a fence is far cheaper, and 
scales much better.
  - Performance counters are important in concurrent applications, and 
are, by definition, performance-critical.
  - We're teaching everyone that AtomicInteger.getAndIncrement is the 
right way to implement a performance counter.
  - So, shouldn't getAndIncrement be able to use the fence-less CAS on 
processors that support it?



More information about the Concurrency-interest mailing list