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

On Thu, Nov 18, 2010 at 11:38 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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.

I don't believe that's correct, although it's possible that I may be
missing something. On any platform where we have TAS(), that should
be sufficient to set the flag, but how will we read the flag? A
simple fetch isn't guaranteed to be sufficient; for some
architectures, you might need to insert a read fence, and I don't
think we have anything like that defined right now. We've got
special-cases in s_lock.h for all kinds of crazy architectures; and
it's not obvious what would be needed. For example some operating
system I've never heard of called SINIX has this:

#include "abi_mutex.h"
typedef abilock_t slock_t;

#define TAS(lock) (!acquire_lock(lock))
#define S_UNLOCK(lock) release_lock(lock)
#define S_INIT_LOCK(lock) init_lock(lock)
#define S_LOCK_FREE(lock) (stat_lock(lock) == UNLOCKED)

It's far from obvious to me how to make this do what we need - I have
a sneaking suspicion it can't be done with those primitives at all -
and I bet neither of us has a machine on which it can be tested. Now
maybe we no longer care about supporting SINIX anyway, but the point
is that if we make this change, every platform for which we don't have
working TAS and read-fence operations becomes an unsupported platform.
Forget about --disable-spinlocks; there is no such thing. That
strikes me as an utterly unacceptable amount of collateral damage to
avoid a basically harmless API change, not to mention a ton of work.
You might be able to convince me that it's no longer important to
support platforms without a working spinlock implementation (although
I think it's rather nice that we can - might encourage someone to try
out PG and then contribute an implementation for their favorite
platform) but this is also going to break platforms that nominally
have TAS now (some of the TAS implementations aren't really TAS, as in
the above case, and we may not be able to easily determine what's
required for a read-fence even where TAS is a real TAS).

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