[concurrency-interest] AtomicReference.updateAndGet() mandatory updating

Hans Boehm boehm at acm.org
Tue May 30 17:48:53 EDT 2017


The details here seem to be a statement about ancient history, at least
where it pertains to write-back cacheable memory.

The "LOCK" prefix description says:

"Beginning with the P6 family processors, when the LOCK prefix is prefixed
to an instruction and the memory area
being accessed is cached internally in the processor, the LOCK# signal is
generally not asserted. Instead, only the
processor’s cache is locked. Here, the processor’s cache coherency
mechanism ensures that the operation is
carried out atomically with regards to memory. See “Effects of a Locked
Operation on Internal Processor Caches”
in Chapter 8 of Intel® 64 and IA-32 Architectures Software Developer’s
Manual, Volume 3A, the for more informa-
tion on locking of caches."

Note that the P6 was introduced in 1995.

I would guess that it does still get exclusive access to the cache line,
even if the compare fails. So I expect that in
some very abstract sense this still applies.

On Tue, May 30, 2017 at 11:56 AM, Aleksey Shipilev <shade at redhat.com> wrote:

> On 05/30/2017 08:23 PM, Hans Boehm wrote:
> > C++ clearly specifies "CAS classic". There is no way to specify release
> > semantics for a failed CAS, since there is no write.
>
> To add to the snowball of confusion here, x86 seems to always do the write
> with
> CAS, even on failure:
>
> Intel SDM, Vol 2A, ISA Reference, "CMPXCHG — Compare and Exchange":
>
> "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.)"
>
> So in x86 work, there *is* a write, but that does not really help us,
> because it
> writes the indistinguishably old value back...
>
> -Aleksey
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20170530/0db9aaec/attachment-0001.html>


More information about the Concurrency-interest mailing list