Re: [Gc] libatomic_ops CAS ordering constraints correspondence to C11 atomic ones

--===============1549007908==
Content-Type: multipart/alternative; boundary=001a113ecff866baf7052ed3f928

--001a113ecff866baf7052ed3f928
Content-Type: text/plain; charset=UTF-8

I agree entirely with the first three.

The last one is debatable.  I agree that the current spec is not very
satisfactory all the way around.  But I believe the current implementations
of _full on architectures where it matters (Power in particular) actually
interpret it as acq_rel for RMW operations.  Without fixing
implementations, I think the last line should read acq_rel | acquire.  For
operations that don't include a read operation, we seem to map _full to
something like a release (if there's a write) plus a trailing seq_cst fence.

If I had to design this again, full would always mean seq_cst, mostly
because I can define that precisely.  But that would slow down Power and
ARMv7 code, and may be a bit much of a revision now.

This library API was a step along the evolution of C/C++ atomics. The
latter are much better defined (though still imperfect).  When this API was
designed, neither I nor anyone else fully appreciated some of the many
subtleties.

Hans

On Thu, Mar 24, 2016 at 1:19 PM, Ivan Maidanski <ivmai-JGs/[email protected]> wrote:

> Hello Hans,
>
> AO Readme.txt is a bit weak in respect to CAS ordering constraints. Let's
> fix it by mapping to C11 atomic memory ordering (based on common sense and
> inspection of libatomic_ops exsiting CAS assembly implementations).
>
> Is the following correct?
> || AO CAS suffix || C11 CAS success || C11 CAS failure ||
> | -            | __ATOMIC_RELAXED | __ATOMIC_RELAXED |
> | acquire | __ATOMIC_ACQUIRE  | __ATOMIC_ACQUIRE |
> | release | __ATOMIC_RELEASE  | __ATOMIC_RELAXED |
> | full        | __ATOMIC_SEQ_CST  | __ATOMIC_ACQUIRE |
>
> [1] https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
> [2] https://github.com/ivmai/libatomic_ops/blob/master/doc/README.txt
>
> --
> Best regards,
> Ivan
>

--001a113ecff866baf7052ed3f928
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I agree entirely with the first three.<div><br></div><div>=
The last one is debatable.=C2=A0 I agree that the current spec is not very =
satisfactory all the way around.=C2=A0 But I believe the current implementa=
tions of _full on architectures where it matters (Power in particular) actu=
ally interpret it as acq_rel for RMW operations.=C2=A0 Without fixing imple=
mentations, I think the last line should read acq_rel | acquire.=C2=A0 For =
operations that don&#39;t include a read operation, we seem to map _full to=
 something like a release (if there&#39;s a write) plus a trailing seq_cst =
fence.</div><div><br></div><div>If I had to design this again, full would a=
lways mean seq_cst, mostly because I can define that precisely.=C2=A0 But t=
hat would slow down Power and ARMv7 code, and may be a bit much of a revisi=
on now.</div><div><br></div><div>This library API was a step along the evol=
ution of C/C++ atomics. The latter are much better defined (though still im=
perfect).=C2=A0 When this API was designed, neither I nor anyone else fully=
 appreciated some of the many subtleties.</div><div><br></div><div>Hans</di=
v></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, M=
ar 24, 2016 at 1:19 PM, Ivan Maidanski <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:ivmai-JGs/[email protected]" target=3D"_blank">ivmai-JGs/[email protected]</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">
<div>Hello Hans,<br><br>AO Readme.txt is a bit weak in respect to CAS order=
ing constraints. Let&#39;s fix it by mapping to C11 atomic memory ordering =
(based on common sense and inspection of libatomic_ops exsiting CAS assembl=
y implementations).<br><br>Is the following correct?<br>|| AO CAS suffix ||=
 C11 CAS success || C11 CAS failure ||<br>| - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0|=C2=A0__ATOMIC_RELAXED |=C2=A0__ATOMIC_RELAXED |<br>| acquire=
 |=C2=A0__ATOMIC_ACQUIRE =C2=A0|=C2=A0__ATOMIC_ACQUIRE |<br>| release |=C2=
=A0__ATOMIC_RELEASE =C2=A0|=C2=A0__ATOMIC_RELAXED=C2=A0|<br>| full =C2=A0 =
=C2=A0 =C2=A0 =C2=A0|=C2=A0__ATOMIC_SEQ_CST =C2=A0|=C2=A0__ATOMIC_ACQUIRE |=
<br><br>[1]=C2=A0<a href=3D"https://gcc.gnu.org/onlinedocs/gcc/_005f_005fat=
omic-Builtins.html" target=3D"_blank">https://gcc.gnu.org/onlinedocs/gcc/_0=
05f_005fatomic-Builtins.html</a><br>[2]=C2=A0<a href=3D"https://github.com/=
ivmai/libatomic_ops/blob/master/doc/README.txt" target=3D"_blank">https://g=
ithub.com/ivmai/libatomic_ops/blob/master/doc/README.txt</a>=C2=A0<span cla=
ss=3D"HOEnZb"><font color=3D"#888888"><br><br>-- <br>Best regards,<br>Ivan<=
/font></span></div>
</blockquote></div><br></div>

--001a113ecff866baf7052ed3f928--

--===============1549007908==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
bdwgc mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/bdwgc
--===============1549007908==--