On Tue, Oct 15, 2013 at 8:33 AM, Andres Freund <and...@2ndquadrant.com> wrote: > 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 *)
We currently assume simple assignment suffices for this. > * 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) Do we really need all of those? Compare-and-swap is clearly needed, and fetch-and-add is also very useful. I'm not sure about the rest. Not that I necessarily object to having them, but it will be a lot more work. > * u64 variants of the above > * bool pg_atomic_test_set(void *ptr) > * void pg_atomic_clear(void *ptr) What are the intended semantics here? > 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 Are these really generally needed? > 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. +1. I have a related problem, which is that some code I'm currently working on vis-a-vis parallelism can run lock-free on platforms with atomic 8 bit assignment but needs a spinlock or two elsewhere. So I'd want to use pg_atomic_store_u64(), but I'd also need a clean way to test, at compile time, whether it's available. More general question: how do we move the ball down the field in this area? I'm willing to do some of the legwork, but I doubt I can do all of it, and I really think we need to make some progress here soon, as it seems that you and I and Ants are all running into the same problems in slightly different ways. What's our strategy for getting something done here? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
