At least in Windows, the theory (edit2: theory of lock convoy mitigation) goes something like this: - There is a queue of threads contending on a lock. - Ther

At least in Windows, the theory (edit2: theory of lock convoy mitigation) goes something like this: - There is a queue of threads contending on a lock. - There are some threads in that group that release the lock, do some context-switchless work, and need the lock again. - In a lock convoy, these would go back to the end of the queue while any other threads that were waiting on the lock now need to be readied and context-switched in. - By instead making the locking unfair and letting the next ready process grab it, there is a better chance that the threads which have quantum slices left will finish out their use of the lock and exit the convoy. Synchronization objects were redesigned in Vista around this mechanism of taking a ready thread instead of the next thread in a fair queue. I suppose something similar is at play in the article ? I don't see how just randomness fixes anything. (edit: formatting)