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

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2008-02-08 18:19:23

Howard Hinnant wrote:
> On Feb 8, 2008, at 2:42 PM, Anthony Williams wrote:
>> Howard Hinnant <hinnant <at> twcny.rr.com> writes:
>>> 3.  The yields are absolutely necessary to get the high performance
>>> mentioned in the previous note.
>>
>> I find this comment intriguing. Is this always the case, or does it  
>> depend on the specifics of how a mutex is implemented on a given platform?
>
> That is a question I've been asking and myself for a long time,  
> unfortunately without a satisfactory answer.  Here's my experience,  
> and a few guesses...

Hi Howard,

If you can share the code, I'll see how it performs on my Linux systems.

I bet it depends greatly on the workload.  I have been considering 
writing an instrumented mutex that records how often it blocks.  In my 
real code, the answer seems to be almost never.

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(....);
}

I'll try to find time to experiment with this soon.

Phil.