This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 0/4] Provide C11 atomic operations
- From: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- To: libc-alpha at sourceware dot org
- Date: Tue, 11 Nov 2014 19:14:48 -0200
- 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> <1415725856 dot 4535 dot 59 dot camel at triegel dot csb>
On 11-11-2014 15:10, Torvald Riegel wrote:
> 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.
>> 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 plan to look a bit mroe at the code generated by a current GCC, but
> otherwise plan to commit this next week. Joseph and Will seem to be
> okay with the patches; if one of you isn't or has additional concerns,
> then please speak up soon.
I have checked the patchset on powerpc64 and powerpc64le and they look ok, no
regressions found. Regarding pthread-once, the code generated is pretty much
the same (the only difference being for first 'atomic_load_acquire' compiler
generates a lwz plus a extsw instead of lwa), however the pthread-once
benchmark does not show difference.