Re: Latches with weak memory ordering (Re: max_wal_senders must die)

On Friday 19 November 2010 05:38:14 Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > I'm all in favor of having some memory ordering primitives so that we
> > can try to implement better algorithms, but if we use it here it
> > amounts to a fairly significant escalation in the minimum requirements
> > to compile PG (which is bad) rather than just a performance
> > optimization (which is good).
> 
> I don't believe there would be any escalation in compilation
> requirements: we already have the ability to invoke stronger primitives
> than these.  What is needed is research to find out what the primitives
> are called, on platforms where we aren't relying on direct asm access.
> 
> My feeling is it's time to bite the bullet and do that work.  We
> shouldn't cripple the latch operations because of laziness at the
> outset.
I don't think developing the code is the actual code is that hard - s_lock.c 
contains nearly everything necessary.
An 'lock xchg' or similar is only marginally slower then  the barrier-only 
implementation. So doing a TAS() on a slock_t in private memory should be an 
easy enough fallback implementation.

So the complicated case seems to be !defined(HAS_TEST_AND_SET) which uses 
spinlocks for that purpose - no idea where that is true these days.

Andres