Hi, IMO it's a bug if S_UNLOCK is a not a compiler barrier.
Moreover for volatile remember: https://www.securecoding.cert.org/confluence/display/seccode/DCL17-C.+Beware+of+miscompiled+volatile-qualified+variables Who is double checking compiler output? :) regards Didier On Fri, Sep 20, 2013 at 5:11 PM, Andres Freund <and...@2ndquadrant.com>wrote: > On 2013-09-20 16:47:24 +0200, Andres Freund wrote: > > I think we should go through the various implementations and make sure > > they are actual compiler barriers and then change the documented policy. > > From a quick look > * S_UNLOCK for PPC isn't a compiler barrier > * S_UNLOCK for MIPS isn't a compiler barrier > * I don't know enough about unixware (do we still support that as a > platform even) to judge > * True64 Alpha I have no clue about > * PA-RISCs tas() might not be a compiler barrier for !GCC > * PA-RISCs S_UNLOCK might not be a compiler barrier > * HP-UX !GCC might not > * IRIX 5 seems to be a compiler barrier > * SINIX - I don't care > * AIX PPC - compiler barrier > * Sun - TAS is implemented in external assembly, normal function call, > compiler barrier > * Win(32|64) - compiler barrier > * Generic S_UNLOCK *NOT* necessarily a compiler barrier. > > Ok, so I might have been a bit too optimistic... > > 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 >
