Re: spinlocks on HP-UX
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Greg Stark <stark@mit.edu>, pgsql-hackers@postgresql.org
Date: 2011-08-29T18:21:50Z
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
Robert Haas <robertmhaas@gmail.com> writes: > I'm actually not convinced that we're entirely consistent here about > what we require the semantics of acquiring and releasing a spinlock to > be. For example, on x86 and x86_64, we acquire the lock using xchgb, > which acts a full memory barrier. But when we release the lock, we > just zero out the memory address, which is NOT a full memory barrier. > Stores can't cross it, but non-dependent loads of different locations > can back up over it. That's pretty close to a full barrier, but it > isn't, quite. Right. That's why I wrote the comment as I did; it says what the actual requirement is. There probably are cases where our implementations are more restrictive than necessary (I hope none where they are weaker). regards, tom lane