[2002-01-05 00:00] Tom Lane said:
| Bruce Momjian <pgman@candle.pha.pa.us> writes:
| > OK, I am a little confused now. I thought the spinlock was only done a
| > few times if we couldn't get a lock, and if we don't we go to sleep, and
| > the count determines how many times we try. Isn't that expected to
| > affect SMP machines?
|
| Yeah, but if the spinlock is only held for a few dozen instructions,
| one would think that the max useful delay is also a few dozen
| instructions (or maybe a few times that, allowing for the possibility
| that other processors might claim the lock before we can get it).
| If we spin for longer than that, the obvious conclusion is that the
| spinlock is held by a process that's lost the CPU, and we should
| ourselves yield the CPU so that it can run again. Further spinning
| just wastes CPU time that might be used elsewhere.
|
| These measurements seem to say there's a flaw in that reasoning.
| What is the flaw?
Knowing very little of SMP, it looks like the spinning is parallelizing
as expected, getting to select() faster, then serializing on the
select() call. I suspect using usleep() instead of select() might
relieve the serialization. I'm aware that usleep(10) will actually
yield between 10 and 20us due to the kernel's scheduler.
b
--
"Develop your talent, man, and leave the world something. Records are
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing." -- Duane Allman
