Feedback-ID: id4a34324:Fastmail
Date: Fri, 23 Feb 2024 17:30:26 -0800
From: Andres Freund <andres@anarazel.de>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
	Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
	pgsql-hackers@postgresql.org
Subject: Re: locked reads for atomics
Message-ID: <20240224013026.t4whp7oqsrfengtd@alap3.anarazel.de>
References: <20231110205128.GB1315705@nathanxps13>
 <20231110231150.fjm77gup2i7xu6hc@alap3.anarazel.de>
 <20231111023813.GB1408159@nathanxps13>
 <20231111024839.op2d2id33x777mll@alap3.anarazel.de>
 <20231111025529.GA1409540@nathanxps13>
 <20231127210030.GA140335@nathanxps13>
 <CALj2ACUOEx_s0DxJL57bsZxQM1+30p_1G9eCZdmsCz45QNprhg@mail.gmail.com>
 <f7519ac5437f1e9f1bd1bb5a4f30fad42eaa6ad7.camel@j-davis.com>
 <20240223161758.GA1697194@nathanxps13>
 <274e5925684e71b0df4f7c0f473b8ce6fc6c382b.camel@j-davis.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <274e5925684e71b0df4f7c0f473b8ce6fc6c382b.camel@j-davis.com>
Archived-At: <https://www.postgresql.org/message-id/20240224013026.t4whp7oqsrfengtd%40alap3.anarazel.de>
Precedence: bulk

Hi,

On 2024-02-23 10:25:00 -0800, Jeff Davis wrote:
> On Fri, 2024-02-23 at 10:17 -0600, Nathan Bossart wrote:
> > The idea is
> > to provide an easy way to remove spinlocks, etc. and use atomics for
> > less
> > performance-sensitive stuff.  The implementations are intended to be
> > relatively inexpensive and might continue to improve in the future,
> > but the
> > functions are primarily meant to help reason about correctness.
> 
> To be clear:
> 
>   x = pg_atomic_[read|write]_membarrier_u64(&v);
> 
> is semantically equivalent to:
> 
>   pg_memory_barrier();
>   x = pg_atomic_[read|write]_u64(&v);
>   pg_memory_barrier();
> ?
> 
> If so, that does seem more convenient.

Kinda. Semantically I think that's correct, however it doesn't commonly make
sense to have both those memory barriers, so you wouldn't really write code
like that and thus comparing on the basis of convenience doesn't quite seem
right.

Rather than convenience, I think performance and simplicity are better
arguments. If you're going to execute a read and then a memory barrier, it's
going to be faster to just do a single atomic operation. And it's a bit
simpler to analyze on which "side" of the read/write the barrier is needed.

Greetings,

Andres Freund