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 brian.curtin, kristjan.jonsson, loewis, pitrou, sbt, tim.golden
Date 2011-03-21.13:43:54
SpamBayes Score 4.7413575e-09
Marked as misclassified No
Message-id <1300715037.44.0.889667362208.issue11618@psf.upfronthosting.co.za>
In-reply-to
Content
> If we are rolling our own instead of using Semaphores (as has been 
> suggested for performance reasons) then using a Condition variable is 
> IMHO safer than a custom solution because the correctness of that 
> approach is so easily provable.

Assuming that you trust the implementation of condition variables, then I agree.  Unfortunately implementing condition variables correctly on Windows is notoriously difficult.  The patch contains the lines

+   Generic emulations of the pthread_cond_* API using
+   Win32 functions can be found on the Web.
+   The following read can be edificating (or not):
+   http://www.cse.wustl.edu/~schmidt/win32-cv-1.html

Apparently all the examples from that web page are faulty one way or another.

http://newsgroups.derkeiler.com/Archive/Comp/comp.programming.threads/2008-07/msg00025.html 

contains the following quote:

> Perhaps this list should provide links to a "reliable" windows
> condition variable implementation instead of continuously bad 
> mouthing the ~schmidt/win32-cv-1.html page and thereby raising 
> it's page rank.  It would greatly help out all us newbies out here.

pthreads-w32 used to use a solution depending on that paper but changed to something else.  The following is a long but relevant read:

ftp://sourceware.org/pub/pthreads-win32/sources/pthreads-w32-2-8-0-release/README.CV

Of course implementing condition variables is a whole lot easier if you don't need to broadcast and you only need weak guarantees on the behaviour.  So python's implementation may be quite sufficient.  (It does appear that a thread which calls COND_SIGNAL() may consume that signal with a later call of COND_WAIT().  A "proper" implementation should never allow that because it can cause deadlocks in code depending on normal pthread sematics.)
History
Date User Action Args
2011-03-21 13:43:57sbtsetrecipients: + sbt, loewis, pitrou, kristjan.jonsson, tim.golden, brian.curtin
2011-03-21 13:43:57sbtsetmessageid: <1300715037.44.0.889667362208.issue11618@psf.upfronthosting.co.za>
2011-03-21 13:43:55sbtlinkissue11618 messages
2011-03-21 13:43:54sbtcreate