Re: [PATCH 0/4] Provide C11 atomic operations

[Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>]

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.