Re: [boost] [thread] best practice to lock multiple mutexes

From: Peter Dimov (pdimov_at_[hidden])
Date: 2008-02-08 18:38:54

Phil Endecott:

> Peter's comment about evil spin-waits in lock() is interesting as I was
> considering implementing something like that.  I wonder about this 
> instead:
>
> void mutex::lock() {
>   if (atomic-attempt-to-lock) { // uncontended
>     return;
>   };
>   // first wait, try yielding since it's fast:
>   sched_yield();
>   if (atomic-attempt-to-lock) { // got lock on 2nd attempt
>     return;
>   }
>   // We failed again.  Maybe there are lots of threads waiting; in that
>   // case it will be more efficient to futex_wait() since the kernel will
>   // then only wake us when our lock has been woken.
>   futex_wait(....);
> }

This isn't very good, either. Consider a scenario where your time slice is 
10ms, but the mutex is unlocked 3ms after you attempt a lock.

In my opinion, mutex::lock should never do fancy stuff behind the user's 
back in an attempt to achieve "better performance". If a 
trylock/sched_yield/lock pattern is better for a specific workload, it can 
be implemented in user space. If it isn't, there is no way to undo the 
damage.