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
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 |