lkml.org 
[lkml]   [2021]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.

\
 
 \ /
  Last update: 2021-07-29 22:05    [W:0.062 / U:0.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site