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

On Fri, Nov 19, 2010 at 10:44 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> 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.
>
> The point I was trying to make is that the fallback position can
> reasonably be a no-op.

Hmm, maybe you're right. I was assuming weak memory ordering was a
reasonably common phenomenon, but if it only applies to a very small
number of architectures and we're pretty confident we know which ones
they are, your approach would be far less frightening than I
originally thought. But is that really true?

I think it would be useful to try to build up a library of primitives
in this area. For this particular task, we really only need a
write-with-fence primitive and a read-with-fence primitive. On strong
memory ordering machines, these can just do a store and a read,
respectively; on weak memory ordering machines, they can insert
whatever fencing operations are needed on either the store side or the
load side. I think it would also be useful to provide macros for
compare-and-swap and fetch-and-add on platforms where they are
available. Then we could potentially write code like this:

#ifdef HAVE_COMPARE_AND_SWAP
...do it the lock-free way...
#else
...oh, well, do it with spinlocks...
#endif

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company