On 2013-10-13 16:56:12 +0200, Tom Lane wrote: > More to the point for this specific case, it seems like our process > ought to be > (1) select a preferably-small set of gcc atomic intrinsics that we > want to use.
I suggest: * pg_atomic_load_u32(uint32 *) * uint32 pg_atomic_store_u32(uint32 *) * uint32 pg_atomic_exchange_u32(uint32 *ptr, uint32 val) * bool pg_atomic_compare_exchange_u32(uint32 *ptr, uint32 *expected, uint32 newval) * uint32 pg_atomic_fetch_add_u32(uint32 *ptr, uint32 add) * uint32 pg_atomic_fetch_sub_u32(uint32 *ptr, uint32 add) * uint32 pg_atomic_fetch_and_u32(uint32 *ptr, uint32 add) * uint32 pg_atomic_fetch_or_u32(uint32 *ptr, uint32 add) * u64 variants of the above * bool pg_atomic_test_set(void *ptr) * void pg_atomic_clear(void *ptr) Ontop of that we can generically implement: * pg_atomic_add_until_u32(uint32 *ptr, uint32 val, uint32 limit) * pg_atomic_(add|sub|and|or)_fetch_u32() * u64 variants of the above We might also want to provide a generic implementation of the math operations based on pg_atomic_compare_exchange() to make it easier to bring up a new architecture. I think we should leave 64bit support optional for now. Opinions? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
