Committed. Thank you for reviewing!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
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
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 i
Hi,
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
> intera
Here is a v3 of the patch set with the first draft of the commit messages.
There are no code differences between v2 and v3.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From f1441aca96f157c5557d9a961fe85902b510f293 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Fri, 23 Feb
On Fri, Feb 23, 2024 at 10:25:00AM -0800, Jeff Davis wrote:
> 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 co
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
On Thu, Feb 22, 2024 at 11:53:50AM -0800, Jeff Davis wrote:
> On Thu, 2024-02-22 at 12:58 +0530, Bharath Rupireddy wrote:
>> There's some immediate use for reads/writes with barrier semantics -
>
> Is this mainly a convenience for safety/readability? Or is it faster in
> some cases than doing an a
On Thu, 2024-02-22 at 12:58 +0530, Bharath Rupireddy wrote:
> There's some immediate use for reads/writes with barrier semantics -
Is this mainly a convenience for safety/readability? Or is it faster in
some cases than doing an atomic access with separate memory barriers?
Regards,
Jeff Da
On Tue, Nov 28, 2023 at 2:30 AM Nathan Bossart wrote:
>
> 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
There's some immediate use for reads/writes with barrier semantics -
https://www.postgresql.or
> On Nov 28, 2023, at 05:00, Nathan Bossart 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
> se
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 exchang
On Fri, Nov 10, 2023 at 06:48:39PM -0800, Andres Freund wrote:
> Yes. We should optimize pg_atomic_exchange_u32() one of these days - it can be
> done *far* faster than a cmpxchg. When I was adding the atomic abstraction
> there was concern with utilizing too many different atomic instructions. I
>
Hi,
On 2023-11-10 20:38:13 -0600, Nathan Bossart wrote:
> On Fri, Nov 10, 2023 at 03:11:50PM -0800, Andres Freund wrote:
> > On 2023-11-10 14:51:28 -0600, Nathan Bossart wrote:
> >> + * This read is guaranteed to read the current value,
> >
> > It doesn't guarantee that *at all*. What it guarante
On Fri, Nov 10, 2023 at 03:11:50PM -0800, Andres Freund wrote:
> On 2023-11-10 14:51:28 -0600, Nathan Bossart wrote:
>> + * This read is guaranteed to read the current value,
>
> It doesn't guarantee that *at all*. What it guarantees is solely that the
> current CPU won't be doing something that c
Hi,
On 2023-11-10 21:49:06 +, John Morris wrote:
> >I wonder if it's worth providing a set of "locked read" functions.
>
> Most out-of-order machines include “read acquire” and “write release” which
> are pretty close to what you’re suggesting.
Is that really true? It's IA64 lingo. X86 doesn
Hi,
On 2023-11-10 14:51:28 -0600, Nathan Bossart wrote:
> Moving this to a new thread and adding it to the January commitfest.
>
> On Thu, Nov 09, 2023 at 03:27:33PM -0600, Nathan Bossart wrote:
> > On Tue, Nov 07, 2023 at 04:58:16PM -0800, Andres Freund wrote:
> >> However, even if there's likel
On Fri, Nov 10, 2023 at 09:49:06PM +, John Morris wrote:
> Most out-of-order machines include “read acquire” and “write release”
> which are pretty close to what you’re suggesting. With the current
> routines, we only have “read relaxed” and “write relaxed”. I think
> implementing acquire/rele
>I wonder if it's worth providing a set of "locked read" functions.
Most out-of-order machines include “read acquire” and “write release” which are
pretty close to what you’re suggesting. With the current routines, we only have
“read relaxed” and “write relaxed”. I think implementing acquire/re
Moving this to a new thread and adding it to the January commitfest.
On Thu, Nov 09, 2023 at 03:27:33PM -0600, Nathan Bossart wrote:
> On Tue, Nov 07, 2023 at 04:58:16PM -0800, Andres Freund wrote:
>> However, even if there's likely some other implied memory barrier that we
>> could piggyback on,
20 matches
Mail list logo
