Is compareAndSet pessimistic?

[Carl Mastrangelo]

Tl;Dr: does CMPXCHG assume it will fail or succeed?

I am on Java 8, and need an atomic boolean.  I don't want to pay higher memory cost, so I am using an AtomicIntegerFieldUpdater.    Right now I have some code that looks 

queue.add(work);

if (running.compareAndSet(this, stopped, running)) {

  executor.execute(queueHandler);

}

I was looking at optimizing this code and noticed that compareAndSet() could be changed to a getAndSet() pretty easily.  Looking at the hotspot code there are three atomic instructions that are used: cmpxchg, xadd, and xchg.

Here is my question: the 2nd and 3rd instructions know for sure they are going to modify the value, so they can bring in the cacheline as modified.  But, cmpxchg could potentially bring the cacheline in as shared/exclusive/owned and not invalidate all the other caches.  If I have special knowledge that I will likely fail to exchange values, then wouldn't it make sense to call get() just before compareAndSet() ?  I wouldn't have to do this is cmpxchg automatically did that for me, but then how could it guess whether it will win or lose?

[Carl Mastrangelo]

Sorry for the double post, but I forgot to include my benchmark numbers, run on a Haswelll processor:

https://gist.github.com/carl-mastrangelo/5f120d91a1a50844cb9582f8eb8aec67

[Tom Lee]

Without trying to wrap my head around the benchmark results, the intel docs seem to imply a write occurs with a LOCK CMPXCHG even if the test fails:

This instruction can be used with a LOCK prefix to allow the instruction to be executed atomically. To simplify the interface to the processor’s bus, the destination operand receives a write cycle without regard to the result of the comparison. The destination operand is written back if the comparison fails; otherwise, the source operand is written into the destination. (The processor never produces a locked read without also producing a locked write.)

(Taken from the CMPXCHG docs in https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf) 

The pseudocode seems to back this up, indicating the "source" value is written back to the destination operand when the test fails.

Given the above I would expect/hope that even if the cmpxchg fails it would still have the semantics of a volatile write, flushing write buffers on the CPU & invalidating the cache line associated with the "unchanged" destination address on other CPUs. Perhaps somebody else knows differently.

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Tom Lee / http://tomlee.co / @tglee

[Avi Kivity]

It can vary by processor, but Intels are optimistic. They assume that
either the operation will succeed, or that you will loop until it does.
If you know it will usually fail, and it's important to you, you can do
your own compare first.

[Alexandr Nikitin]

Carl, you may find the Joe Duffy's "Some performance implications of CAS operations" post interesting http://joeduffyblog.com/2009/01/08/some-performance-implications-of-cas-operations/