On Fri, Nov 19, 2010 at 10:01 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@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.
I completely agree, but I'm not too sure I want to drop support for
any platform for which we haven't yet implemented such primitives.
What's different about this case is that "fall back to taking the spin
lock" is not a workable option.
> 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.
That's good to hear. I'm more worried, however, about architectures
where we supposedly have TAS but it isn't really TAS but some
OS-provided "acquire a lock" primitive. That won't generalize nicely
to what we need for this case.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company