http://bugs.winehq.org/show_bug.cgi?id=26500
--- Comment #6 from Vladimir Voznesensky vvoznesensky@gmail.com 2011-03-22 04:16:14 CDT --- (In reply to comment #5)
(In reply to comment #4)
Please, look _carefully_ at pthread_mutex_lock realization. It uses both futexes and events!
...
lock variable is used for futex AND event is used for kernel synchronization!
How does it make this bug more valid?
Windows implementation does not have to busy wait forever. Look http://msdn.microsoft.com/en-us/library/ms682530.aspx :
Spinning means that when a thread tries to acquire a critical section that is locked, the thread enters a loop, checks to see if the lock is released, and if the lock is not released, the thread goes to sleep. ... if the critical section is unavailable, the calling thread spins dwSpinCount times before performing a wait operation on a semaphore that is associated with the critical section. If the critical section becomes free during the spin operation, the calling thread avoids the wait operation.
As you can see, a kernel synchro object is used in Windows for waiting the thread owning the lock. The same behaviour (except spinning) is realized in libpthread. So, why should WineLib have a very different suboptimal behaviour?