From the MSDN is not really clear its purpose.
Can it be used to simulate an intensive CPU calculation test?
When you do multi-threaded locking, if the resource you're attempting to acquire is already locked, you typically go to sleep and wait for it to become free. When you do this, you give up the rest of the time that you were allocated by the scheduler to use the processor so someone else can have a go. Normally this is fine, especially for long waits, like waiting for IO, loads of other processes can run on the CPU while you're waiting for the disk spindle to rotate.
However, sometimes, you're waiting for a tiny amount of time. In these cases, you would normally give up your remaining time anyway and wait for all the other threads to do their thing before getting another go.. so you can cheat, instead of waiting, you sit there continually polling in a 'are we nearly there yet?' way. If the lock is only held for a fraction of your remaining time, this becomes a very effective means of waiting, its also very efficient as the scheduler doesn't have to get involved in rearranging all the other threads to use the time you give up if you waited normally.
Obviously, if you spin every time you want a lock, you're not going to be very popular, your app will become sluggish and use 100% CPU, but in very small doses, at the right time, it makes the app more responsive.
If you're now thinking 'when should I use it?', that's a tricky call to make - if you have a resource that is very often locked and unlocked very quickly, then a spinlock around that instead of a wait is a good idea (and then test your app for performance), if you try spinning for a short time, and then fall back to a normal wait, that's a reasonable way too. But generally, you will never need to use it.
The purpose is to do a "cheap" wait if you believe that the condition you're waiting for will come true very, very soon. Normally if you're waiting for something, you let the thread go to sleep and the processor/OS will context switch to another thread. Context switches aren't particularly cheap, so if you have advanced knowledge of the situation and believe it's cheaper to wait than to context switch, you spin wait.
My advice: if you need to ask, you don't need to use it. (I've never wanted it myself.) Basically it's one of those things which is really useful in a very few situations, but most people should leave well alone.
As a side note, Microsoft have gotten rid of the thread dispatcher spinlock mechanism from Windows 7, since it didn't scale well for multicore CPU's. Have a look at this:
As far as I'm concerned (and I'm happy for corrections!), the only use of spin waits is when implementing a locking or inter-thread-callback mechanism. And neither should be done manually (usually), since they already exist.
When you've locked a resource and another thread requests synchronized access to it, it basically has to wait for the first thread to finish using it. This waiting can be done by simply spinning in a loop (or otherwise sleeping + context switching as mentioned by Jon).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With