Kristján Valur Jónsson <krist...@ccpgames.com> added the comment: Martin, I´ve explained it in my other dissue, issue 8411, with a step by step example. It is unfair because a thread can _bypass_ the condition variable. A thread just woken up from the condition variable has to race to get the lock, and it is a race that it will invariably loose if the other thread is doing a release/acquire (yielding the GIL as happens in ceval.py) The ConditionVariable can only endow the lock with its fairness property if all the threads play by the same rules.
This was a design decision made by Tim (according to the comment) but a misguided one. It is a good stragegy for resources that are held for a short time to avoid lock convoying, but not appropriate in this case. You also don't have to take my word for it. Just try it out. Notice that 99% of all yields between threads fail, causing starvation of a thread which is the definition of "unfairness." Anyway, this is the last time I explain why the "emulated" semaphore is unfair. I think I´ve done so on at least four or five different occasions and it would be helpful if people would actually bother to read my comments. ---------- _______________________________________ 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
