[LnxPrgr3]

A couple nits to pick:

(1) Mutex performance isn't constant by OS. My own measurements tell me FreeBSD and Linux are around 20x slower than Linux locking and unlocking a mutex in the uncontended case.

(2) Contention makes mutexes a lot slower. If a mutex is already locked, you have to wait until it unlocks before you can proceed. It doesn't matter how fast mutexes are if there's a thread locking the one you're waiting on for seconds at a time. And even if other threads aren't holding the mutex long, putting the waiting thread to sleep involves a syscall, which is relatively expensive.

[lallysingh]

A good part of contention's cost can be the time you wait for the thread scheduler. When the lock-holding thread releases, your thread is moved from 'sleeping' to 'ready', and then it's gotta wait for a CPU. This is usually fast, but the tail can be awful.

[LnxPrgr3]

Erm… I meant FreeBSD and Mac OS X have slower mutexes than Linux. Not sure how that sentence slipped by me.

[Nick_C]

Is that still the case for FreeBSD? I thought they did some work this year to help speed it up. Also, the Linux emulation under FreeBSD was always slow for mutex (did you test under Linux emulation or native?), but they have implemented futexes now and pushed uncontended mutex to userspace to speed it up.

[LnxPrgr3]

I tested under native, but you raise an important point—IIRC I was testing with FreeBSD 7.1, and seeing as 9.0 is out it's definitely worth a retest.