Skip site navigation (1) Skip section navigation (2)

Re: spinlocks on HP-UX

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: spinlocks on HP-UX
Date: 2011-08-29 18:41:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Greg Stark <stark(at)mit(dot)edu> writes:
> I was going to say the same thing as Tom that sequence points and
> volatile pointers have nothing at all to do with each other. However
> my brief searching online actually seemed to indicate that in fact the
> compiler isn't supposed to reorder volatile memory accesses across
> sequence points. That seemed to make sense since I couldn't think of
> any other way to rigorously describe the constraints the compiler
> should operate under.

It's a bit confusing.  I agree that if the code is written such that
there are two volatile accesses with no intervening sequence point,
the compiler is at liberty to do them in either order; for instance in

	foo(*x, *y);

there are no guarantees about which value is fetched first, even if x
and y are volatile-qualified.  What's bothering me is that in, say,

	*x = 0;
	*y = 1;
	*z = 2;

if x and z are volatile-qualified but y isn't, I believe the compilers
think they are only required to store into *x before *z, and can reorder
the store to *y around either of the others.  So this makes the notion
of a sequence point pretty squishy in itself.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2011-08-29 18:48:12
Subject: Re: spinlocks on HP-UX
Previous:From: Alvaro HerreraDate: 2011-08-29 18:41:38
Subject: Re: [GENERAL] pg_upgrade problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group