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