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. On Sat, Sep 23, 2017 at 10:15 PM, 'Carl Mastrangelo' via mechanical-sympathy <[email protected]> wrote: > 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? > > -- > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee> -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
