Re: spinlocks on HP-UX - Mailing list pgsql-hackers

From Robert Haas
Subject Re: spinlocks on HP-UX
Date
Msg-id CA+TgmoYnDkOdUQMyvPM9viJ3ewemdik1RK+tjtWKpv6N2xd6-Q@mail.gmail.com
Whole thread Raw
In response to Re: spinlocks on HP-UX  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: spinlocks on HP-UX
Re: spinlocks on HP-UX
List pgsql-hackers
On Mon, Aug 29, 2011 at 12:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Greg Stark <stark@mit.edu> writes:
>> The confusion for me is that it's talking about sequence points and
>> volatile pointers in the same breath as if one implies the other.
>> Making something a volatile pointer dose not create a sequence point.
>> It requires that the compiler not move the access or store across any
>> sequence points that are already there.
>
> Well, no, I don't think that's the useful way to think about it.  Modern
> compilers seem to only honor sequence points in terms of the semantics
> seen by the executing program; they don't believe that they can't
> reorder loads/stores freely.

This discussion seems to miss the fact that there are two levels of
reordering that can happen.  First, the compiler can move things
around.  Second, the CPU can move things around.  Even on x86, for
example, a sequence like this can be reordered:

LOAD A
STORE A
LOAD B

Even though the compiler may emit those instructions in exactly that
order, an x86 CPU can, IIUC, decide to load B before it finishes
storing A, so that the actual apparent execution order as seen by
other CPUs will be either the above, or the above with the last two
instructions reversed.  On a weakly ordered CPU, the load of B could
be moved back even further, before the LOAD of A.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Join push-down for foreign tables
Next
From: hubert depesz lubaczewski
Date:
Subject: Re: [GENERAL] pg_upgrade problem