Re: Spinlocks and compiler/memory barriers

On Tue, Sep 9, 2014 at 5:09 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-09-09 13:52:40 -0400, Robert Haas wrote:
>> I had forgotten that it needed an update.  Thanks for the reminder.  Here's v2.
>
> I've attached a incremental patch fixing minor gripes. Other than that I
> think you can go ahead with this once the buildfarm accepts the sparc
> fixes (man, those machines are slow. spoonbill apparently takes ~5h for
> one run).
>
> I've done a read through s_lock.h and the only remaining potential issue
> that I see is that I have no idea if unixware's tas() is actually a safe
> compiler barrier (it is a memory barrier). And I really, really can't
> make myself care.
 *    It is the responsibility of these macros to make sure that the compiler *    does not re-order accesses to shared
memoryto precede the actual lock
 
- *    acquisition, or follow the lock release.  Prior to PostgreSQL 9.5, this
- *    was the caller's responsibility, which meant that callers had to use
+ *    acquisition, or following the lock release.  Prior to PostgreSQL 9.5,
+ *  this was the caller's responsibility, which meant that callers had to use

AFAICS my version is right and your version is grammatically
incorrect. "re-order to proceed or follow" uses the same verb tense in
both branches of the or; "re-order to proceed or following" does not.

I agree that if there are problems on UnixWare, we can let anyone who
cares about UnixWare submit a patch to fix them.

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