On architectures capable of halting, most operating system initiate a halt when things go idle. The halt is broken at the next interrupt.Originally Posted by DougDbug
Also, most OS kernels use spinlocks as the underlying lock primitive to implement more advanced locking. Spinlocks are busy loops, but they don't spin for very long. Only a few cycles at the most.
If you have an embedded system with "wait loops", it's either so trivial that it only needs an 8-bit micorcontroller and half a dozen kilobytes of code, or it's very badly designed.
Wait-loops is a waste of useful processing time.
And like brewbuck says, the "idle" in a modern processor is a HLT instruction, which is a way to say "Wait here until an interrupt comes in". Much more efficient than a loop, as the HLT instruction allows the processor to stop fetching, decoding and executing instructons, saving power in the process.
Yes, there are situations where short busy/wait loops are necessary to force correct behaviour. spin-locks are the only way to wait when the schedular can't be run - a "sleep" waiting method won't work here, because that requires the scheduler to run. This is typically in the interrupt section of a driver or similar places. Of course, all accesses to the data accessed by the interrupt section must be protected by the same spinlock Also, spinlock enter should block interrupts, or you could dead-lock by having the same lock held by the non-interrupt path, and the interrupt coming in - if we hold a spin-lock. Spin-locks are often only implemented on SMP machines, and in the non-SMP systems, the same code is protected by a simple "block interrupts" instruction. This should naturally not be done for long running pieces of code - if that ends up being the case, you probably should redesign the data-model.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
