Re: pgsql: Add pg_atomic_unlocked_write_u64

Hi,

On 2025-12-04 10:03:22 -0600, Nathan Bossart wrote:
> On Thu, Dec 04, 2025 at 10:56:12AM -0500, Andres Freund wrote:
> > The whole point of the _unlocked_ function is to use it for modifying an
> > atomic that doesn't need to actually be atomic when modified by that
> > function. The current use-case for it is to to modify BufferDesc->state for
> > temporary table buffers. Those obviously can't be shared across processes and
> > therefore don't need an atomic operation to be modified. In the referenced
> > thread I'm working on converting BufferDesc->state to be a 64bit atomic, hence
> > the need for pg_atomic_unlocked_write_u64().
> >
> > I didn't notice that the comment for pg_atomic_unlocked_write_u32() makes that
> > claim about partial writes not being visible. I think we should just remove
> > that claim.
>
> +1 to updating the comment with this context.

Hm. Aside from the above issue, the reference to atomics emulation in the
comment is also obsolete since 81385261362.

How about:

/*
* pg_atomic_unlocked_write_u32 - unlocked write to atomic variable.
*
* Write to an atomic variable, without atomicity guarantees. I.e. it is not
* guaranteed that a concurent reader will not see a torn value, nor to
* guaranteed to correctly interact with concurrent read-modify-write
* operations like pg_atomic_compare_exchange_u32. This should only be used
* in cases where minor performance regressions due to atomic operations are
* unacceptable and where exclusive access is guaranteed due to some external
* means.
*
* No barrier semantics.
*/

We could actually guarantee, in the 32bit case, that a concurrent reader would
not see a torn value, but ISTM that any such user should not use _unlocked_,
and this way we don't need separate documentation for the 64bit case.

Greetings,

Andres Freund