Robert Haas <robertmh...@gmail.com> writes:
> If we're going to work on memory primitives, I would much rather see
> us put that effort into, say, implementing more efficient LWLock
> algorithms to solve the bottlenecks that the MOSBENCH guys found,
> rather than spending it on trying to avoid a minor API complication
> for the latch facility.
I haven't read all of this very long thread yet, but I will point out
that you seem to be arguing from the position that memory ordering
primitives will only be useful for the latch code. This is nonsense
of the first order. We already know that the sinval signalling
mechanism could use it to avoid needing a spinlock. I submit that
it's very likely that fixing communication bottlenecks elsewhere
will similarly require memory ordering primitives if we are to avoid
the stupid "use a lock" approach. I think it's time to build that
infrastructure.
BTW, I agree with Andres' point that we can probably default memory
barriers to be no-ops on unknown platforms. Weak memory ordering
isn't a common architectural choice. A look through s_lock.h suggests
that PPC and MIPS are the only supported arches that need to worry
about this.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
