From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Nathan Bossart <nathandbossart@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: pgsql: Add pg_atomic_unlocked_write_u64
Date: Thu, 04 Dec 2025 13:15:55 -0500
Message-ID: <1139398.1764872155@sss.pgh.pa.us> (raw)
In-Reply-To: <dro4puw7jwi5ukp4wxudg6an62qdjxqtsmqj4kwg3362ajk4mw@cz3otplhnmxl>
References: <E1vQwSk-002fZh-2h@gemulon.postgresql.org>
<aTGt7q4Jvn97uGAx@nathan>
<6a7i4g5rroen3jyok4jxpd76tpg7nkicq4o75cdprp5thdlkbn@dfwr7ts43rsm>
<aTGwysvF2lDmK2lP@nathan>
<dro4puw7jwi5ukp4wxudg6an62qdjxqtsmqj4kwg3362ajk4mw@cz3otplhnmxl>
Andres Freund <andres@anarazel.de> writes:
> 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
grammar police: s/nor to/nor is this/
> * 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.
> */
LGTM otherwise.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, nathandbossart@gmail.com, pgsql-hackers@lists.postgresql.org
Subject: Re: pgsql: Add pg_atomic_unlocked_write_u64
In-Reply-To: <1139398.1764872155@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox