This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author kristjan.jonsson
Recipients beazley, dabeaz, flox, kristjan.jonsson, loewis, pitrou, r.david.murray, techtonik, torsten
Date 2010-04-18.20:40:43
SpamBayes Score 8.097412e-12
Marked as misclassified No
Message-id <1271623246.19.0.887018383428.issue8299@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2010-04-18 20:40:46kristjan.jonssonsetrecipients: + kristjan.jonsson, loewis, beazley, pitrou, techtonik, r.david.murray, flox, dabeaz, torsten
2010-04-18 20:40:46kristjan.jonssonsetmessageid: <1271623246.19.0.887018383428.issue8299@psf.upfronthosting.co.za>
2010-04-18 20:40:44kristjan.jonssonlinkissue8299 messages
2010-04-18 20:40:43kristjan.jonssoncreate