Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| 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> |
* 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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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