Re: Some interesting results from tweaking spinlocks
От | Tom Lane |
---|---|
Тема | Re: Some interesting results from tweaking spinlocks |
Дата | |
Msg-id | 12237.1010252769@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Some interesting results from tweaking spinlocks (mlw <markw@mohawksoft.com>) |
Список | 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 по дате отправления: