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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
