Re: Freezing without write I/O - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Freezing without write I/O
Date
Msg-id 20130923160840.GB5284@awork2.anarazel.de
Whole thread Raw
In response to Re: Freezing without write I/O  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2013-09-23 11:50:05 -0400, Robert Haas wrote:
> 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.

Yea :(. I think we should start by trimming the above list by removing
some platforms:
* SINIX - doesn't actually seem to be supported
* Tru64 - not even a zombie anymore
* IRIX - ...

The others probably can't be removed?

> 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.

Yes, the memory clobber is missing for PPC and MIPS.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Freezing without write I/O
Next
From: Peter Geoghegan
Date:
Subject: Re: logical changeset generation v6