Re: better atomics - Mailing list pgsql-hackers

From Andres Freund
Subject Re: better atomics
Date
Msg-id 20131106145448.GA28314@alap2.anarazel.de
Whole thread Raw
In response to Re: better atomics  (Ants Aasma <ants@cybertec.at>)
Responses Re: better atomics
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Ants Aasma
Date:
Subject: Re: better atomics
Next
From: Peter Eisentraut
Date:
Subject: Re: UNION ALL on partitioned tables won't use indices.