homepage

Here is yet another point:
if _POSIX_SEMAPHORES is defined, thread_pthread.h is designed to use the (fair) semaphore. If it is not present, or HAVE_BROKEN_POSIX_SEMAPHORES defined, the semaphore is supposed to be emulated using a condition variable.
Now, I don't have access to a mac or linux machine, but does a modern python build perhaps actually have USE_SEMAPHORES defined? if so, then this entire rant about a broken lock on pthreads is nonsense.
Please note that the "emulated" semaphore is unfair, as I've pointed out, whereas a posix_sem object strives to be fair. So this "emulation" is not working..
Martin, you are right that some mutexes are indeed fair. There has been a move towards using unfair mutexes, particularly on multicore machines. This is because they reduce the "lock convoying" problem.
A fair mutex hands off the lock to a waiting thread. That thread is then made runnable. But on a busy system, it may take a while for that thread to actually start running and use the locked resource. The reesult is that the locked resource is unavailable for a longer time. An unfair mutex will wake up a waiting thread, yet have that thread compete for the mutex with any interloper that might arrive and claim it. See e.g. http://www.bluebytesoftware.com/blog/PermaLink,guid,e40c2675-43a3-410f-8f85-616ef7b031aa.aspx and http://developer.amd.com/documentation/articles/Pages/282007123.aspx