[concurrency-interest] AtomicReferenceweakCompareAndSet "Mayfailspuriously"?
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
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
To summarize Cliff's argument, which is entirely motivated by practical
- The specification of CAS currently requires a full fence.
- Some processors support CAS operations that do not require full
- 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