Re: [Boost-users] Q: N00b spinlock

Subject: Re: [Boost-users] Q: N00b spinlock
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2010-01-20 23:17:16

On Wed, Jan 20, 2010 at 10:00 PM, Moritz Moeller <boost_at_[hidden]> wrote:
> I'm new to multi-threaded programming. So I apologize for aksing what is
> possibly a silly question.
>
> Will below code give me the behaviour of what is commonly called a
> "spinlock"?
>
>
>  boost::unique_lock< boost::shared_mutex >
>    guard( mutex, boost::try_to_lock );
>
>  if ( !guard.owns_lock() ) {
>    while ( !guard.try_lock() ) {
>      boost::thread::yield();
>    }
>  }
>
>  // access data
>
> Cheers,
>
> Moritz

No.  A spinlock is for cases where you don't use a mutex (for whatever
reason).  If you have a mutex, just wait on it:

    mutex.lock(); // yield to other threads until we can get the mutex
    // now have mutex, do some work...
    mutex.unlock();

A spinlock spins on a simple variable:

   static int lock = 0;

   // lock the lock
   while (XCHG(&lock, 1) != 0)
      yield();

   do_work();

   // unlock
   XCHG(&lock, 0);

Where XCHG ("exchange') is an atomic operation that sets lock to 1 and
returns the old value - atomically! ie in a single 'step' that can't
be interrupted.  It also, and this is important, it also does the
proper memory barriers to ensure that other memory instructions do not
get reordered to happen before it.  (The CPU can reorder your memory
reads/writes otherwise - as an optimization technique.)

If the old value (returned by XCHG) was already 1, your 'set' didn't
really do anything, the lock was already held by someone else.
So yield() to others than try again.
If the old (returned) value was 0, then no one else had the lock right
before you set it to 1, so you now have it. Leave the while() loop.

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.

If you are new to multi-threading, stick to simple mutex
locking/unlocking (using scoped_lock etc).

Once you are experienced with MT programming, STILL stick to simple
mutex locking/unlocking.

Tony