Tom Lane wrote:
> 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?
My guess is that the lock is held for more than a few instructions, at
least in some cases. Spin/increment is a pretty fast operation with no
access of RAM. Could the overhead of the few instructions be more than
the spin time, or perhaps there is a stall in the cpu cache, requiring
slower RAM access while the spin counter is incrementing rapidly?
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
