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