Hi,
On 2017-04-03 11:56:13 -0700, Andres Freund wrote:
>
> > +/*
> > + * Generic implementation of pg_atomic_fetch_mask_add_u32() via loop
> > + * of compare & exchange.
> > + */
> > +static inline uint32
> > +pg_atomic_fetch_mask_add_u32_impl(volatile pg_atomic_uint32 *ptr,
> > + uint32 mask_,
> > uint32 add_)
> > +{
> > + uint32 old_value;
> > +
> > + /*
> > + * Read once outside the loop, later iterations will get the newer value
> > + * via compare & exchange.
> > + */
> > + old_value = pg_atomic_read_u32_impl(ptr);
> > +
> > + /* loop until we've determined whether we could make an increment or
> > not */
> > + while (true)
> > + {
> > + uint32 desired_value;
> > + bool free;
> > +
> > + desired_value = old_value;
> > + free = (old_value & mask_) == 0;
> > + if (free)
> > + desired_value += add_;
> > +
> > + /*
> > + * Attempt to swap in the value we are expecting. If we didn't
> > see
> > + * masked bits to be clear, that's just the old value. If we
> > saw them
> > + * as clear, we'll attempt to make an increment. The reason
> > that we
> > + * always swap in the value is that this doubles as a memory
> > barrier.
> > + * We could try to be smarter and only swap in values if we saw
> > the
> > + * maked bits as clear, but benchmark haven't shown it as
> > beneficial
> > + * so far.
> > + *
> > + * Retry if the value changed since we last looked at it.
> > + */
> > + if (pg_atomic_compare_exchange_u32_impl(ptr, &old_value,
> > desired_value))
> > + return old_value;
> > + }
> > + pg_unreachable();
> > +}
> > +#endif
>
> Have you done x86 benchmarking?
I think unless such benchmarking is done in the next 24h we need to move
this patch to the next CF...
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
