Re: Some interesting results from tweaking spinlocks

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: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Some interesting results from tweaking spinlocks
Date: 2002-01-05 05:52:12
Message-ID: 10199.1010209932@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:
> Isn't there tons more lock contention on an SMP machine.

No, one would hope not. If you can't get the various processes to
run without much interference, you're wasting your time dealing
with multiple CPUs.

In a uniprocessor, we'll suffer from lock contention if one process
happens to lose the CPU while holding a lock, and one of the other
processes that gets to run meanwhile tries to acquire that same lock.
In SMP this gets folded down: the lock holder might not lose its CPU
at all, but some other CPU could be running a process that tries to
acquire the lock meanwhile. It's not apparent to me why that should
increase the chance of lock contention, however. The percentage of
a process' runtime in which it is holding a lock should be the same
either way, so the probability that another process fails to acquire
the lock when it wants shouldn't change either. Where is the flaw
in this analysis?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-01-05 06:08:39 Re: Some interesting results from tweaking spinlocks
Previous Message Bruce Momjian 2002-01-05 05:41:48 Re: Some interesting results from tweaking spinlocks