Re: Spinlocks and compiler/memory barriers

On Tue, Sep 9, 2014 at 6:00 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-09-09 17:54:03 -0400, Robert Haas wrote:
>> So, that's committed, then.
>
> Yay, finally.
>
>> I think we should pick something that uses
>> spinlocks and is likely to fail spectacularly if we haven't got this
>> totally right yet, and de-volatilize it.  And then watch to see what
>> turns red in the buildfarm and/or which users start screaming.
>
> Good plan.
>
>> I'm inclined to propose lwlock.c as a candidate, since that's very
>> widely used and a place where we know there's significant contention.
>
> I suggest, additionally possibly, GetSnapshotData(). It's surely one of
> the hottest functions in postgres, and I've seen some performance
> increases from de-volatilizing it. IIRC it requires one volatile cast in
> one place to enforce that a variable is accessed only once. Not sure if
> we want to add such volatile casts or use something like linux'
> ACCESS_ONCE macros for some common types. Helps to grep for places
> worthy of inspection.

GetSnapshotData() isn't quite to the point, because it's using a
volatile pointer, but not because of anything about spinlock
manipulation.  That would, perhaps, be a good test for barriers, but
not for this.

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