[PATCH v2] Add and use new glibc-internal futex API.

[Torvald Riegel]

On Wed, 2015-06-17 at 22:55 +0000, Joseph Myers wrote:
> On Wed, 17 Jun 2015, Roland McGrath wrote:
> 
> > > Interacting with futex words requires atomic accesses, which isn't done
> > > by most of glibc's current futex callers. [...]
> > 
> > I certainly concur with leaving this until later.  What I think will be
> > reasonable to do eventually is to use the <stdatomic.h> type names in
> > all our internal interfaces (probably only atomic_int or atomic_uint
> > should be used for futex stuff).  When building with older compilers
> > that don't have those, our own internal headers can typedef the ones
> > we use to the simple types (or perhaps volatile-qualified ones?).
> 
> Those types imply seq_cst memory order for plain loads and stores, which 
> isn't what's wanted in most places in glibc (one might expect many places 
> presently using plain loads and stores actually want relaxed memory 
> order).

I agree.  We should always have explicit memory orders for all atomic
accesses.  The default seq_cst MO is very likely to be just unnecessary
runtime overhead, yet if we pick a weaker MO it should always be a
conscious choice.

> Operations on _Atomic types may also bring in libatomic 
> dependencies depending on processor support, causing obvious problems with 
> circular dependencies (libatomic depends on libpthread).

Agreed.  Though if looking at just the required functionality, we expect
the glibc atomics to always either use atomic HW instructions or a
kernel helper; if we'd end up using locks to synchronize because there's
no other support for the atomics we're using, we'd be doing something
wrong in glibc.