On Mon, Jul 6, 2026 at 9:31 PM Heikki Linnakangas <[email protected]> wrote: > > On 06/07/2026 18:05, Ashutosh Bapat wrote: > > On Mon, Jul 6, 2026 at 3:57 AM Heikki Linnakangas <[email protected]> wrote: > > > >> > >> I think that's because I think of pg_atomic_flag as an atomic version of > >> "bool". I'd assume there to be functions similar to the u32/u64 > >> functions, like pg_atomic_read_bool() and pg_atomic_write_bool(). But > >> alas, neither of those functions exist. To read the value, you have to > >> use pg_atomic_unlocked_test_flag(), and remember that when the flag is > >> set, it returns *false*, which feels completely backwards to me. It > >> makes more sense with pg_atomic_test_set_flag(), which returns 'false' > >> if the flag was already set and hence was not set again, but it > >> nevertheless just feels wrong to me. > >> > > > > I am using pg_atomic_test_set_flag() as a non-wait locking, lighter > > than LWLock mechanism in shared buffer resizing patches. That might > > change in future. But I think there's use for TAS kind of semantics. > > But I have also got confused when looking at it as pg_atomic_bool. I > > think we need both. > > The functionality is still there with my patch, as the > pg_atomic_exchange_bool() function. Would that work for you?
I think I can use it by replacing pg_atomic_test_set_flag(ab) by !pg_atomic_exchange_bool(ab, true). I haven't tried it. Maybe just define pg_atomic_test_set_flag(ab) as !pg_atomic_exchange_bool(ab, true) to be readable? Right now, none of the callers of pg_atomic_test_set_flag() check its return value (thus use it as TAS). So maybe we can add pg_atomic_test_set_flag() as a separate patch. -- Best Wishes, Ashutosh Bapat
