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.