Re: Some interesting results from tweaking spinlocks

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