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 sbt
Recipients kristjan.jonsson, loewis, paul.moore, pitrou, python-dev, sbt, vstinner
Date 2012-06-19.17:14:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1340126099.49.0.539635321803.issue15038@psf.upfronthosting.co.za>
In-reply-to
Content
> It's an interesting article Richard, but I don't see how their 2nd attempt 
> solves the problem.  All it does is block the thread doing the Signal(), 
> not other threads, from stealing the wakeup.

Do you mean the listing on page 5?  (The earlier attempts were failures.)  The signalling thread holds the lock "x" while issuing the signal "s.V()" and waiting for notification of wakeup "h.P()".  A new thread cannot steal the wakeup because it needs to acquire the lock "x" before it can start its wait.

Of course, if the main mutex is always held when doing signal()/broadcast() then the lock "x" is unnecessary.

I don't think trying to do a full emulation is necessary.  Better to just document the limitations.
History
Date User Action Args
2012-06-19 17:14:59sbtsetrecipients: + sbt, loewis, paul.moore, pitrou, kristjan.jonsson, vstinner, python-dev
2012-06-19 17:14:59sbtsetmessageid: <1340126099.49.0.539635321803.issue15038@psf.upfronthosting.co.za>
2012-06-19 17:14:58sbtlinkissue15038 messages
2012-06-19 17:14:57sbtcreate