homepage

> 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.)