Boost logo

Boost :

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-10-26 05:34:42

Scott wrote:
> I'm writing an application that runs on both Win32 (vs 2005) and Linux
> (gcc).

I can say something about Linux.

> Relatively speaking, how much time does it cost to
> 1) Locking the mutex initially and increment the lock count
> Vs
> 2) Determine that a mutex is already locked by the thread and just increment
> the lock count?
> I'm also curious how much faster mutex is over recursive_mutex for both
> platforms. If anybody has done performance profiling or just knows in
> general the different mutex scenario performance costs, I'd greatly
> appreciate any info. :)

It's very easy to measure this yourself by timing something like

mutex m;
for (int i=0; i<1000000000; ++i) {
   scoped_lock l(m);

and comparing with

recursive_mutex rm;
scoped_lock l1(rm);
for (int i=0; i<1000000000; ++i) {
   scoped_lock l2(m);

My understanding is that Boost has a fairly thin layer on top of
pthreads, and you can see the source for the pthreads implementation here:

It looks like it does what you would expect:

switch (kind-of-mutex) {

   case recursive:
     if (owner = me) {

   case normal:


When uncontended, the implementation of lock() should be a single
atomic instruction.

My guess would be that locking an already-locked recursive mutex would
be a fraction faster than locking an unlocked non-recursive mutex - by
maybe a nanoseconds or so. If you measure it, let me know if I was right.

If you really care about these sorts of differences you might want to
consider avoiding the pthreads layer altogether; see my recent posts
about using the futex() system call directly.



Boost list run by bdawes at, gregod at, cpdaniel at, john at