On 2013-11-06 16:48:17 +0200, Ants Aasma wrote: > C11 atomics need to be initialized through atomic_init(), so a simple > typedef will not be correct here. Also, C11 atomics are designed to > have the compiler take care of memory barriers - so they might not > always be a perfect match to our API's, or any API implementable > without compiler support.
Yea, I think we'll always need to have our layer above C11 atomics, but it still will be useful to allow them to be used to implement our atomics. FWIW, I find the requirement for atomic_init() really, really annoying. Not that that will change anything ;) > However I'm mildly supportive on having a separate type for variables > accessed by atomics. It can result in some unnecessary code churn, but > in general if an atomic access to a variable is added, then all other > accesses to it need to be audited for memory barriers, even if they > were previously correctly synchronized by a lock. Ok, that's what I am writing right now. > I guess the best approach for deciding would be to try to convert a > couple of the existing unlocked accesses to the API and see what the > patch looks like. I don't think there really exist any interesting ones? I am using my lwlock reimplementation as a testbed so far. 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
