Typically you shouldn't use spinlocks, unless you are working really low level and know what you are doing, and if do_work() is very short - ie a few processor instructions.
Well, what I am doing is setting two boolean flags. This happens in an app where interactivity/responsiveness if of utmost importance. I'm writing a plugin for this app.
you could have a look at the proposed boost.atomic library, implementing c++0x-style atomics.
Once you are experienced with MT programming, STILL stick to simple mutex locking/unlocking.
So why would these people use spinlocks?
spinlocks are usually faster to acquire and release than mutexes, but require busy waiting, which may be cause an overall performance impact if the critical section takes some time to execute (especially, if the critical section itself is blocking). a calling thread would be suspended when waiting for a mutex to be locked, which could lead to some issues for certain (actually very little) use cases. nevertheless, i would be happy to see spinlocks and reader-writer spinlocks as part of boost.thread. they could easily be implemented via boost.atomic. tim -- tim@klingt.org http://tim.klingt.org Silence is only frightening to people who are compulsively verbalizing. William S. Burroughs