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: Joseph Myers <joseph at codesourcery dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Torvald Riegel <triegel at redhat dot com>, GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Wed, 17 Jun 2015 22:55:40 +0000
- 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>
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). Operations on _Atomic types may also bring in libatomic
dependencies depending on processor support, causing obvious problems with
circular dependencies (libatomic depends on libpthread).
--
Joseph S. Myers
joseph@codesourcery.com