Re: [PATCH] Add atomic operations required by the new condition variable.

[Torvald Riegel <triegel at redhat dot com>]

On Fri, 2016-05-27 at 11:13 +0200, Florian Weimer wrote:
> On 05/26/2016 01:04 AM, Torvald Riegel wrote:
> > +# ifndef atomic_exchange_relaxed
> > +/* XXX This unnecessarily has acquire MO.  */
> 
> I don't understand the use of the XXX marker here.  If there is a 
> potential bug, this needs a longer explanation.  If this is just use of 
> an unnecessarily strong memory order, a generic remark somewhere in the 
> file that âarchitectures might override the following defines with 
> relaxed MO implementation for improved performanceâ or something like 
> that should address this, and that doesn't warrant an XXX marker.

It's not a bug, but a less-than-ideal implementation.  What's the marker
for this then?  (Having no marker isn't ideal because then we can't grep
for this, for example.)

Architectures should not do their arch-custom stuff in atomics if they
can.  Note that the XXX is on code in #if !USE_ATOMIC_COMPILER_BUILTINS
so it will go away eventually once arch maintainers confirm that the new
atomic builtins work on their machines.

> (Ideally, our atomics and how to implement them should be documented in 
> internals manual,

I've said it before and it still stands: C11 is the documentation for
the new-style atomics we use.  This is documented on the concurrency
page on the wiki.  What else is there that would need to be documented?

> or we should use GCC atomics directly so that we don't 
> need our own documentation.

We do in cases where they are available and somebody has checked that it
works.  More arch-maintainers setting USE_ATOMIC_COMPILER_BUILTINS to 1
would be a good thing.

> But that's an old and separate discussion. 
> Using the GCC syntax would also avoid the unfortunate naming pattern, 
> e.g. âatomic_fetch_or_releaseâ.)

Remember that this isn't just an arbitrarily chosen naming pattern, but
follows the C11 names with the difference that we always make the memory
order an explicit part of the operation's name.  IOW, if people know C11
atomics, it's *very* easy for them to use ours.  In the long run, more
developers will know C11 atomics than GCC atomic builtins.

There are two major reasons for including the memory order name:
1) We want developers to always think about which memory order is
necessary.
2) We don't want to clash with C11 function names (eg, if we should
choose to switch to C11 in the future).  But once we move to C11, the
switch will be simple and mechanical.