Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.std.c > #6348

Re: atomic_compare_exchange atomicity of write to *expected

From Florian Weimer <fw@deneb.enyo.de>
Newsgroups comp.std.c
Subject Re: atomic_compare_exchange atomicity of write to *expected
Date 2021-10-11 07:51 +0200
Message-ID <87zgrgp0rj.fsf@mid.deneb.enyo.de> (permalink)
References <sjhadm$4uu$1@solani.org> <20211008132058.19c078b9@coosemans.org>

Show all headers | View raw


* Tijl Coosemans:

> On Tue, 5 Oct 2021 12:46:13 +0200 Philipp Klaus Krause <pkk@spth.de>
> wrote:
>> For the atomic_compare-exchange family, e.g.
>> 
>> _Bool atomic_compare_exchange_strong(volatile A *object, C *expected, C
>> desired);
>> 
>> the description states "Atomically, compares the contents of the memory
>> pointed to by object for equality with that pointed to by expected, and
>> if true, replaces the contents of the memory pointed to by object with
>> desired, and if false, updates the contents of the memory pointed to by
>> expected with that pointed to by object."
>> 
>> This reads to me as if the write to *expected is also part of the atomic
>> operation. This doesn't map well to compare-and-swap hardware
>> instructions, where the content of *object would be written to a
>> register, and later stored into *expected by a separate instruction.
>> 
>> Of course, this difference only matters if it is observable. I think it
>> is observable if just after the compare-and swap, a second thread writes
>> *object, while the first thread has already done the comparison, but not
>> yet updated *expected.
>> Then e.g. a thread thread could read the new value from *object, but the
>> old one from *expected, which is not possible if
>> atomic_compare_exchange_strong is fully atomic (i.e. also wrt. *expected).
>> 
>> Is my understanding here correct (I'm not an expert on atomics)?
>
> *expected has type C, so it's not atomic, but even if it was, the
> compare-and-swap, reading of *object, and reading of *expected are three
> different operations and anything can happen in between them.

And there are very few CPUs which can actually implement an atomic
updated of *expected as well.  Since the intent is that
atomic_compare_exchange maps to a typical CAS instruction, it's
apparent hat an atomic update of *expected can't be the intended
meaning.

I do think that the wording in the standard is ambiguous, though.

Back to comp.std.c | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

atomic_compare_exchange atomicity of write to *expected Philipp Klaus Krause <pkk@spth.de> - 2021-10-05 12:46 +0200
  Re: atomic_compare_exchange atomicity of write to *expected Tijl Coosemans <tijl@coosemans.org> - 2021-10-08 13:20 +0200
    Re: atomic_compare_exchange atomicity of write to *expected Florian Weimer <fw@deneb.enyo.de> - 2021-10-11 07:51 +0200
      Re: atomic_compare_exchange atomicity of write to *expected Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-18 05:50 -0800
  Re: atomic_compare_exchange atomicity of write to *expected Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-09 03:04 -0700

csiph-web