This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2] Add and use new glibc-internal futex API.
- From: Torvald Riegel <triegel at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Thu, 18 Jun 2015 12:06:19 +0200
- Subject: Re: [PATCH v2] Add and use new glibc-internal futex API.
- Authentication-results: sourceware.org; auth=none
- References: <1434575216 dot 5250 dot 204 dot camel at localhost dot localdomain> <20150617224653 dot C66822C3B00 at topped-with-meat dot com> <alpine dot DEB dot 2 dot 10 dot 1506172250160 dot 24249 at digraph dot polyomino dot org dot uk>
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.