Re: locked reads for atomics - Mailing list pgsql-hackers

From Li, Yong
Subject Re: locked reads for atomics
Date
Msg-id 74EA538A-5857-4CEC-8B70-1AD4AF69994C@ebay.com
Whole thread Raw
In response to Re: locked reads for atomics  (Nathan Bossart <nathandbossart@gmail.com>)
List pgsql-hackers

> On Nov 28, 2023, at 05:00, Nathan Bossart <nathandbossart@gmail.com> wrote:
> 
> External Email
> 
> Here's a v2 of the patch set in which I've attempted to address all
> feedback.  I've also added a pg_write_membarrier_u* pair of functions that
> provide an easy way to write to an atomic variable with full barrier
> semantics.  In the generic implementation, these are just aliases for an
> atomic exchange.
> 
> 0002 demonstrates how these functions might be used to eliminate the
> arch_lck spinlock, which is only ever used for one boolean variable.  My
> hope is that the membarrier functions make eliminating spinlocks for
> non-performance-sensitive code easy to reason about.
> 
> (We might be able to use a pg_atomic_flag instead for 0002, but that code
> seems intended for a slightly different use-case and has more complicated
> barrier semantics.)
> 
> --
> Nathan Bossart
> Amazon Web Services: https://aws.amazon.com

Hi Nathan,

The patch looks good to me.

The patch adds two pairs of atomic functions that provide full-barrier semantics to atomic read/write operations. The
patchalso includes an example of how this new functions can be used to replace spin locks.
 

The patch applies cleanly to HEAD. “make check-world” also runs cleanly with no error.  I am moving it to Ready for
Committers.

Regards,
Yong

pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: [PoC] Improve dead tuple storage for lazy vacuum
Next
From: Tom Lane
Date:
Subject: Re: New Window Function: ROW_NUMBER_DESC() OVER() ?