Messages in this thread | | | Date | Thu, 29 Jul 2021 22:03:29 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH] Documentation/atomic_t: Document forward progress expectations |
| |
On Fri, Jul 30, 2021 at 12:24:14AM +0800, hev wrote: > We may need new APIs to help LL/SC to implement atomic operations, but > this is obviously incompatible with native CAS. and many and many > common functions are CAS friendly. Let's more functions that implement > atomic semantics can be overridden by architecture may be a way. ;-) > > In the above example, the correct implementation on LL/SC may be like: > > do { > old = LL(&v); > new = func(old, &skip); > if (skip) { > break; > } > } while (!SC(&v, new); > > However, the success of SC may be affected by the inconstant > complexity of func. :-(
Right, so you can't really do that because the architecture constraints on what is allowed between LL and SC vary. Also, you couldn't compile that code on a CAS architecture because you simply cannot implement the LL/SC semantics using CAS.
One thing that can be done is having the compiler transform a CAS loop into a LL/SC loop, and clang actually tries that, but GCC is absolutely failing there:
https://godbolt.org/z/1MK6ceq46
(note; clang only does this for arm64, and the code it does generate is pretty horrific)
And this is another thing where C11 is utter crap; because as far as it's concerned this is equivalent, while obviously it is not, per the parent argument.
Also, ideally there would be a variant where you'd mandate the forward progress or a compiler error when not possible.
| |