Re: [PATCH] x86: Optimize atomic_compare_and_exchange_[val|bool]_acq [BZ #28537]

["H.J. Lu" <hjl.tools@gmail.com>]

On Wed, Nov 3, 2021 at 12:21 PM Arjan van de Ven <arjan@linux.intel.com> wrote:
>
> On 11/3/2021 10:17 AM, Andreas Schwab wrote:
> > On Nov 03 2021, Arjan van de Ven via Libc-alpha wrote:
> >
> >> What the patch does is check non-atomic first if the actual atomic operation has
> >> a chance of working. if it has a chance, the actual normal atomic operation is done as
> >> before. But if non-atomic read already tells you the cmpxchg has no chance to succeed, it errors
> >> out early.
> >
> > But if the compiler keeps reusing the same cached value it may conclude
> > that the CAS _never_ has a chance to succeed.
>
> that's a good point. Now there SHOULD be a (compiler) barrier around this somewhere due
> to inserting the pause instruction for such a loop. But putting some explicit compiler barrier in this
> makes it for sure safer.

Like this?

#define atomic_compare_and_exchange_val_acq(mem, newval, oldval) \
  ({ __typeof (*(mem)) oldmem = *(mem), ret;                            \
     atomic_read_barrier ();                                            \
     ret = (oldmem == (oldval)                                          \
            ? __sync_val_compare_and_swap (mem, oldval, newval)         \
            : oldmem);                                                  \
     ret; })
#define atomic_compare_and_exchange_bool_acq(mem, newval, oldval) \
  ({ __typeof (*(mem)) oldmem = *(mem);                                 \
     atomic_read_barrier ();                                            \
     int ret;                                                           \
     ret = (oldmem == (oldval)                                          \
            ? !__sync_bool_compare_and_swap (mem, oldval, newval)       \
            : 1);                                                       \
     ret; })


-- 
H.J.