From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: locked reads for atomics |
Date: | 2024-02-24 15:27:34 |
Message-ID: | 20240224152734.GA1862419@nathanxps13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 23, 2024 at 05:34:49PM -0800, Andres Freund wrote:
> On 2024-02-23 14:58:12 -0600, Nathan Bossart wrote:
>> +/*
>> + * pg_atomic_write_membarrier_u32 - write with barrier semantics.
>> + *
>> + * The write is guaranteed to succeed as a whole, i.e., it's not possible to
>> + * observe a partial write for any reader. Note that this correctly interacts
>> + * with both pg_atomic_compare_exchange_u32() and
>> + * pg_atomic_read_membarrier_u32(). While this may be less performant than
>> + * pg_atomic_write_u32() and pg_atomic_unlocked_write_u32(), it may be easier
>> + * to reason about correctness with this function in less performance-sensitive
>> + * code.
>> + *
>> + * Full barrier semantics.
>> + */
>
> The callout to pg_atomic_unlocked_write_u32() is wrong. The reason to use
> pg_atomic_unlocked_write_u32() is for variables where we do not ever want to
> fall back to spinlocks/semaphores, because the underlying variable isn't
> actually shared. In those cases using the other variants is a bug. The only
> use of pg_atomic_unlocked_write_u32() is temp-table buffers which share the
> data structure with the shared buffers case.
I removed the reference to pg_atomic_unlocked_write_u32().
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Attachment | Content-Type | Size |
---|---|---|
v4-0001-Introduce-atomic-read-write-functions-with-full-b.patch | text/x-diff | 6.1 KB |
v4-0002-Convert-archiver-s-force_dir_scan-variable-to-an-.patch | text/x-diff | 2.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2024-02-24 17:10:12 | Re: incremental backup mishandles XLOG_DBASE_CREATE_FILE_COPY |
Previous Message | James Coleman | 2024-02-24 13:56:41 | Re: RFC: Logging plan of the running query |