This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 0/4] Provide C11 atomic operations
- From: Will Newton <will dot newton at linaro dot org>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Wed, 5 Nov 2014 14:04:54 +0000
- Subject: Re: [PATCH 0/4] Provide C11 atomic operations
- Authentication-results: sourceware.org; auth=none
- References: <1414617613 dot 10085 dot 23 dot camel at triegel dot csb>
On 29 October 2014 21:20, Torvald Riegel <email@example.com> wrote:
> This patch set provides support for C11-like atomic operations. It does
> not change existing code that that uses the current atomic ops, so
> callers of atomic ops can be changed one algorithm at a time. (To
> illustrate such changes, the last patch transforms pthread_once to use
> C11 atomics.)
> The atomic ops all have C11 semantics but use different names to avoid
> naming collisions with C11 operations. If we should require C11
> compilation at some time in the future, transforming the calls of all
> atomic operations will be easy.
> This expects, of course, that we use the C11 model. The only difference
> is that I've chosen to not explicitly use atomic types, but rather just
> use atomic operations on plain data types. This will work for existing
> code that is transformed. For new code, it can mean that programmers
> have to be careful to use the right alignment if the atomic ops on a
> particular arch come with such constraints.
> If we get consensus for that, we can change to using atomic types in a
> second phase.
> After acceptance of this patch set, I can provide additional
> documentation on the wiki. However, I'd like to get some input on how
> much (ie, how much detail, etc.) documentation you would like to see.
> One reason to move to C11 is to not have contributors have to learn
> something new, so I guess that the glibc-specific documentation we'd
> need would be rather small in size.
This series looks good to me as a starting point for switching to C11
If we can agree on this approach it would be useful to get the patches
merged in good time so any further atomic optimizations or conversions
can happen before 2.21.
Toolchain Working Group, Linaro