On 2024-Apr-05, Jeff Davis wrote: > Minor comments:
> * Also, I assume that the Max() call in > pg_atomic_monotonic_advance_u64() is just for clarity? Surely the > currval cannot be less than _target when it returns. I'd probably just > do Assert(currval >= _target) and then return currval. Uhh ... my understanding of pg_atomic_compare_exchange_u64 is that *expected is set to the value that's stored in *ptr prior to the exchange. Its comment * Atomically compare the current value of ptr with *expected and store newval * iff ptr and *expected have the same value. The current value of *ptr will * always be stored in *expected. is actually not very clear, because what does "current" mean in this context? Is the original "current" value, or is it the "current" value after the exchange? Anyway, looking at the spinlock-emulated code for pg_atomic_compare_exchange_u32_impl in atomics.c, /* perform compare/exchange logic */ ret = ptr->value == *expected; *expected = ptr->value; if (ret) ptr->value = newval; it's clear that *expected receives the original value, not the new one. Because of this behavior, not doing the Max() would return the obsolete value rather than the one we just installed. (It would only work correctly without Max() when our cmpxchg operation "fails", that is, somebody else incremented the value past the one we want to install.) Another reason is that when I used pg_atomic_monotonic_advance_u64 with the Write and Flush pointers and did not have the Max(), the assertion failed pretty quickly :-) -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ Al principio era UNIX, y UNIX habló y dijo: "Hello world\n". No dijo "Hello New Jersey\n", ni "Hello USA\n".