Author kristjan.jonsson
Recipients beazley, dabeaz, flox, kristjan.jonsson, loewis, pitrou, techtonik, torsten
Date 2010-04-15.14:09:19
SpamBayes Score 0.000348739
Marked as misclassified No
Message-id <>
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.,guid,e40c2675-43a3-410f-8f85-616ef7b031aa.aspx and
Date User Action Args
2010-04-15 14:09:22kristjan.jonssonsetrecipients: + kristjan.jonsson, loewis, beazley, pitrou, techtonik, flox, dabeaz, torsten
2010-04-15 14:09:22kristjan.jonssonsetmessageid: <>
2010-04-15 14:09:20kristjan.jonssonlinkissue8299 messages
2010-04-15 14:09:19kristjan.jonssoncreate