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 →
  1. Typo fixes.

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