Re: spinlocks: generalizing "non-locking test" - Mailing list pgsql-hackers

From Tom Lane
Subject Re: spinlocks: generalizing "non-locking test"
Date
Msg-id 9528.1098036828@sss.pgh.pa.us
Whole thread Raw
In response to spinlocks: generalizing "non-locking test"  (Neil Conway <neilc@samurai.com>)
Responses Re: spinlocks: generalizing "non-locking test"
List pgsql-hackers
Neil Conway <neilc@samurai.com> writes:
> Currently x86 is the only platform on which we do this -- ISTM that all 
> the other platforms that implement spinlocks via atomic operations could 
> benefit from this technique.

Do you have any actual evidence for that opinion?  ISTM this is
dependent on a large set of assumptions about the CPU's bus behavior,
boiling down to the conclusion that an extra conditional branch is
cheaper than a locked bus cycle.  It would be a serious error to
transfer that conclusion to non-Intel chips without investigation.
(For that matter, I'm not that thrilled about it even for the Intel
chips, since the extra test is certainly 100% wasted cycles on any
single-CPU machine, or indeed anywhere that the lock is not contended
for.)

I believe that an extra test would be a dead loss on PPC, for instance,
because the initial load is already nonblocking there.

>      if (*lock == 0)
>          TAS(lock);

This will certainly not work on HPPA, and it really shouldn't assume
that zero is the non-locked state, and what happened to testing the
TAS result?

On the whole it seems far easier to stick an extra load into the asm
code on those platforms where we think it's a win.  Especially since
we have already done that ;-)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 7.4 changes
Next
From: Bruce Momjian
Date:
Subject: Open Items