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