This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 0/4] Provide C11 atomic operations
- From: Torvald Riegel <triegel at redhat dot com>
- To: GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Thu, 20 Nov 2014 16:02:58 +0100
- 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 Wed, 2014-10-29 at 22:20 +0100, Torvald Riegel 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.
I have committed this patch after some more code comparison for x86_64
pthread_once using a current GCC, and a regression check on x86_64. The
fast path has identical code. On the slow path, there are some minor
differences in which instructions are used, but I didn't spot anything
hat looked significant.
I've also fixed the Changelog; Adhemerval, thanks for spotting this.
> 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.
I've started a draft of guidelines for concurrency in glibc, including
how to document concurrent code, at
https://sourceware.org/glibc/wiki/Concurrency
These are my opinions, so please have a look and let me know if you
disagree with something or want to see further information.