Re: Some interesting results from tweaking spinlocks

mlw <markw(at)mohawksoft(dot)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