Zitat von Tim Blechmann
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.
http://www.chaoticmind.net/~hcb/projects/boost.atomic/doc/atomic/usage_examp...
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.
I have experimented with spinlocks within my library, and even if I only use them for mutexes whose locks are usually very short-lived I could produce usecases that end up in a performance-desaster, with 80% CPU consumed by yield() system calls. especially when 3 or more threads contend about a mutex, so 2 of them are yield()ing: if thread 1 has acquired the mutex and thread 2 and 3 are yield()ing, it seems the scheduler constantly switches between threads 2 and 3 until they´ve used up a full time slot until thread 1 is continued and releases the lock. I guess there are some use cases for pure spinlocks, without yield()ing, if you know that you have > 1 CPUs and the locks are short-lives, but I ended up using not a single spinlock. a combination of a Boost.Atomic atomic<> and a boost::mutex I found useful however: combined_mutex() : atomic_count(-1){ this->system_mutex.lock(); } lock(){ if(atomic_count.fetch_add(1,...) >= 0){ this->system_mutex.lock(); } } unlock(){ if(atomic_count.fetch_sub(1,...) > 0){ this->system_mutex.unlock(); } } for low-contention mutexes that's faster than calling pthread for every lock.