From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: locked reads for atomics |
Date: | 2023-11-11 02:55:29 |
Message-ID: | 20231111025529.GA1409540@nathanxps13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
> didn't really agree back then, but these days I really don't see a reason to
> not use a few more intrinsics.
I might give this a try, if for no other reason than it'd force me to
improve my mental model of this stuff. :)
>> It refers to "unlocked writes," but this isn't
>> pg_atomic_unlocked_write_u32_impl(). The original thread for this comment
>> [0] doesn't offer any hints, either. Does "unlocked" mean something
>> different here, such as "write without any barrier semantics?"
>
> It's just about not using the spinlock. If we were to *not* use a spinlock
> here, we'd break pg_atomic_compare_exchange_u32(), because the
> spinlock-implementation of pg_atomic_compare_exchange_u32() needs to actually
> be able to rely on no concurrent changes to the value to happen.
Thanks for clarifying. I thought it might've been hinting at something
beyond the compare/exchange implications.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2023-11-11 02:56:24 | Re: remaining sql/json patches |
Previous Message | Erik Rijkers | 2023-11-11 02:52:42 | Re: remaining sql/json patches |