Re: How does spin count really works

Bass Chorng wrote:
> I have a question on how spin counting really works.

I don't know how Oracle does it, but I've implemented spin-counting. First up, you should *only* spin on a multi-CPU system. The idea of spinning rather than yielding (to another thread) is that the latch may be yielded (by another *CPU*) while spinning - so you check the latch on each spin. Of course if you're spinning on a single-CPU system, the only way the latch can be released is if your spinning thread gets preempted - so it's much better to just yield immediately. Also if the thread which is holding the latch is on the same CPU.

The spin count is chosen based on the average cost of execution of a latched section, vs the cost of the context switch associated with yielding.

> If it is the latter, how does it know that latch is available halfway?

It's in shared memory, accessed by a bus-synchronised instruction.

> If it is the former, then my question extends to why would a
> larger value in _spin_count increase the chance getting the latch?

Because the latch should only be held in short sections of code, so if a thread on another CPU has the latch, you only need to spin a little while before the latch gets released and so you avoid the cost of rescheduling. If the latch gets held longer, but still less than the cost of yielding and rescheduling another thread, then a longer spin count will get it. In no case should the spin count exceed the cost of rescheduling a thread.

Clifford Heath, ManageSoft. Received on Mon Nov 08 2004 - 23:58:37 CST