Re: Some interesting results from tweaking spinlocks - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Some interesting results from tweaking spinlocks
Date
Msg-id 12237.1010252769@sss.pgh.pa.us
Whole thread Raw
In response to Re: Some interesting results from tweaking spinlocks  (mlw <markw@mohawksoft.com>)
List pgsql-hackers
mlw <markw@mohawksoft.com> writes:
> A better lock system could know how many CPUs are in a system, and how many
> processes are waiting for the lock. Use this information to manage who sleeps
> and who spins.
> For instance, if you have a 2 CPU SMP box, the first process to get the lock
> gets it. The next process to try for the lock should spin. The third process
> waiting should sleep.

Actually, the thing you want to know before deciding whether to spin is
whether the current lock holder is running (presumably on some other
CPU) or is waiting to run.  If he is waiting then it makes sense to
yield your CPU so he can run.  If he is running then you should just
spin for the presumably short time before he frees the spinlock.
On a single-CPU system this decision rule obviously reduces to "always
yield".

Unfortunately, while we could store the PID of the current lock holder
in the data structure, I can't think of any adequately portable way to
do anything with the information :-(.  AFAIK there's no portable kernel
call that asks "is this PID currently running on another CPU?"
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: RC1 time?
Next
From: Oleg Bartunov
Date:
Subject: Re: RC1 time?