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.