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 kristjan.jonsson, loewis, paul.moore, pitrou, python-dev, sbt, vstinner
Date 2012-06-19.16:08:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1340122091.94.0.361443633227.issue15038@psf.upfronthosting.co.za>
In-reply-to
Content
Right.
Without holding the mutex, the definition of "already blocked" is of course meaningless, since only the holding the mutex can define any ordering.
pthread standard indeed says "however, if predictable scheduling behaviour is required, then that mutex is locked by the thread calling pthread_cond_signal() or pthread_cond_broadcast()."

There are a number of implementations that are subjects to serious problems if the mutex isn't held when doing pthread_cond_signal(), including the notorious 'lost wakeup' bug, eg:  http://docs.oracle.com/cd/E19963-01/html/821-1601/sync-21067.html, so it is certainly recommended practice to use pthread_cond_signal() with the mutex held regardless.

But you are right, the emulation implementation depends on the mutex not only for predicable scheduling but for synchronizing access to the internal state, and this should be documented.
History
Date User Action Args
2012-06-19 16:08:11kristjan.jonssonsetrecipients: + kristjan.jonsson, loewis, paul.moore, pitrou, vstinner, python-dev, sbt
2012-06-19 16:08:11kristjan.jonssonsetmessageid: <1340122091.94.0.361443633227.issue15038@psf.upfronthosting.co.za>
2012-06-19 16:08:11kristjan.jonssonlinkissue15038 messages
2012-06-19 16:08:10kristjan.jonssoncreate