[issue11618] Locks broken wrt timeouts on Windows

sbt report at bugs.python.org
Mon Mar 21 14:43:57 CET 2011


sbt <shibturn at gmail.com> added the comment:

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

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11618>
_______________________________________


More information about the Python-bugs-list mailing list