Re: spinlocks on HP-UX
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Greg Stark <stark@mit.edu>
Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2011-08-29T18:41:49Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Typo fixes.
- 0510b62d9115 9.2.0 cited
Greg Stark <stark@mit.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