On 2013-10-01 04:47:42 +0300, Ants Aasma wrote:
> I still think we should have a macro for the volatile memory accesses.
> As a rule, each one of those needs a memory barrier, and if we
> consolidate them, or optimize them out, the considerations why this is
> safe should be explained in a comment. Race prone memory accesses
> should stick out like a sore thumb.
Agreed. The "wait free LW_SHARED" thing[1] I posted recently had a simple
#define pg_atomic_read(atomic) (*(volatile uint32 *)&(atomic))
That should be sufficient and easily greppable, right?
I generally think we need to provide some primitives for doing atomic
stuff. There's lots of stuff that's not easy to accelerate further without.
Greetings,
Andres Freund
[1] http://archives.postgresql.org/message-id/20130926225545.GB26663%40awork2.anarazel.de
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
