On Friday 19 November 2010 05:38:14 Tom Lane wrote: > Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
