On Fri, Sep 20, 2013 at 11:11 AM, Andres Freund <andres@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...
Yeah, it seems worth fixing, but it's not going to be a 5-minute
project, I fear.
But why do you think that this is not a compiler barrier (PPC):
__asm__ __volatile__ (" sync \n"); \ *((volatile slock_t *) (lock)) = 0; \
Surely, the __asm__ __volatile__ must be a compiler barrier, but the
compiler could presumably allow the store to the lock itself to move
forward past other non-volatilized stores during optimization? Is
that what you're concerned about? If so, that's easily fixed by
sticking __asm__ __volatile__("":::"memory") in there. But some of
the other cases are less clear.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company