[PATCH 1/2] S390: Optimize atomic macros.

[Torvald Riegel]

On Fri, 2016-12-16 at 18:08 +0100, Stefan Liebler wrote:
> On 12/09/2016 04:16 PM, Stefan Liebler wrote:
> > On 11/24/2016 01:51 PM, Torvald Riegel wrote:
> >> On Wed, 2016-11-23 at 16:09 +0100, Stefan Liebler wrote:
> >>> The atomic_compare_and_exchange_val_acq macro is now implemented with
> >>> gcc __sync_val_compare_and_swap instead of an inline assembly with
> >>> compare-and-swap instruction.
> >>
> >> Can you use the new GCC atomic builtins, or are they still insufficient
> >> on s390?
> >>
> >> Related to that, can you define USE_ATOMIC_COMPILER_BUILTINS to 1?
> >> Generally, this is where we want to get to, so that we have to maintain
> >> as few atomic operations as possible.
> >>
> >> Also note that we'll be phasing out the old-style glibc atomics
> >> eventually and use the new C11-like atomics.
> > I've activated it and tried an example like this (also compare it with
> > pthread_once):
> > int
> > foo (int *lock)
> > {
> >   int val, newval;
> >   val = atomic_load_acquire (lock);
> >   do
> >     {
> >       newval = val | 123;
> >     }
> >   while (!atomic_compare_exchange_weak_acquire (lock, &val, newval));
> >
> >   return 0;
> > }
> >
> > The assembly produced by GCC 5.4/6.2 contains a new stack-frame, the old
> > value is stored and loaded to/from the stack-frame before the
> > cs-instruction.
> > After the cs, the old value is stored again and reloaded if a further
> > round of cs is needed.
> > The condition-code of cs is extracted into a register and then compared
> > to determine if a further round of cs is needed.

Having read your other message, did you try with an int* or volatile
int* lock?