Re: spinlocks: generalizing "non-locking test"

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: spinlocks: generalizing "non-locking test"
Date: 2004-10-19 04:43:15
Message-ID: 1098160995.1113.147.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2004-10-18 at 11:53, Tom Lane wrote:
> Only once we've begun to spin. The first time through, it's not at all
> clear whether the extra test is worthwhile --- it's certainly a win if
> the lock is always already held, and certainly a loss if the lock is
> always free

Granted, but I think you've mostly conceded my point: every _subsequent_
time TAS() is invoked, the non-locking test is a clear win (with the
possible exception of PPC). Therefore we have two cases: "initial TAS"
and "TAS inside loop", so so the logical implementation is two distinct
macros. Of course, there may well be platforms on which TAS() is defined
to TAS_INNER_LOOP() or vice versa, but this decision will vary by
platform.

> you have to do some benchmarking to decide if you want it or not.

I agree that benchmarking is worth doing before making changes.

> We have the ASM-level test on those platforms
> where people seem to think that it is worthwhile, but not everywhere.

That is certainly an optimistic interpretation :-) I would say an
equally likely theory is that there is only one platform on which people
have bothered to try a non-blocking test and see if it improves
performance, and accordingly we only have one platform on which a
non-locking test is used.

(If anyone out there _has_ modified the spinlock implementation for
PostgreSQL on a particular platform to use a non-locking initial test
and found it hasn't improved performance, please speak up.)

-Neil

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Browne 2004-10-19 05:15:30 Re: embedded postgresql
Previous Message Philip Warner 2004-10-19 00:51:33 Re: Using ALTER TABLESPACE in pg_dump