Re: Performance TODO items

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Performance TODO items
Date: 2001-07-30 19:29:12
Message-ID: 21804.996521352@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Should we be spinning waiting for spinlock on multi-cpu machines? Is
> that the answer?

A multi-CPU machine is actually the only case where a true spinlock
*does* make sense. On a single CPU you might as well yield the CPU
immediately, because you have no chance of getting the lock until the
current holder is allowed to run again. On a multi CPU it's a
reasonable guess that the current holder is running on one of the other
CPUs and may release the lock soon ("soon" == less than a process
dispatch cycle, hence busy-wait is better than release CPU).

We are currently using spinlocks for a lot of situations where the mean
time spent holding the lock is probably larger than "soon" as defined
above. We should have a different lock implementation for those cases.
True spinlocks should be reserved for protecting code where the maximum
time spent holding the lock is guaranteed to be very short.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Darren King 2001-07-30 19:32:50 RE: Performance TODO items
Previous Message Tom Lane 2001-07-30 19:24:01 Re: Performance TODO items