Kristján Valur Jónsson <krist...@ccpgames.com> added the comment: 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 ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8299> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
