Skip to content

Commit 0006aac

Browse files
committed
Issue python#15038: Document caveats with the emulated condition variables.
1 parent 066dacf commit 0006aac

File tree

1 file changed

+29
-0
lines changed

1 file changed

+29
-0
lines changed

Python/condvar.h

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -13,6 +13,28 @@
1313
* PyCOND_TIMEDWAIT, in addition to returning negative on error,
1414
* thus returns 0 on regular success, 1 on timeout
1515
* or 2 if it can't tell.
16+
*
17+
* There are at least two caveats with using these condition variables,
18+
* due to the fact that they may be emulated with Semaphores on
19+
* Windows:
20+
* 1) While PyCOND_SIGNAL() will wake up at least one thread, we
21+
* cannot currently guarantee that it will be one of the threads
22+
* already waiting in a PyCOND_WAIT() call. It _could_ cause
23+
* the wakeup of a subsequent thread to try a PyCOND_WAIT(),
24+
* including the thread doing the PyCOND_SIGNAL() itself.
25+
* The same applies to PyCOND_BROADCAST(), if N threads are waiting
26+
* then at least N threads will be woken up, but not necessarily
27+
* those already waiting.
28+
* For this reason, don't make the scheduling assumption that a
29+
* specific other thread will get the wakeup signal
30+
* 2) The _mutex_ must be held when calling PyCOND_SIGNAL() and
31+
* PyCOND_BROADCAST().
32+
* While e.g. the posix standard strongly recommends that the mutex
33+
* associated with the condition variable is held when a
34+
* pthread_cond_signal() call is made, this is not a hard requirement,
35+
* although scheduling will not be "reliable" if it isn't. Here
36+
* the mutex is used for internal synchronization of the emulated
37+
* Condition Variable.
1638
*/
1739

1840
#ifndef _CONDVAR_H_
@@ -134,10 +156,17 @@ PyCOND_TIMEDWAIT(PyCOND_T *cond, PyMUTEX_T *mut, long us)
134156
without bound. This also helps reduce the number of "spurious wakeups"
135157
that would otherwise happen.
136158
159+
This implementation still has the problem that the threads woken
160+
with a "signal" aren't necessarily those that are already
161+
waiting. It corresponds to listing 2 in:
162+
http://birrell.org/andrew/papers/ImplementingCVs.pdf
163+
137164
Generic emulations of the pthread_cond_* API using
138165
earlier Win32 functions can be found on the Web.
139166
The following read can be edificating (or not):
140167
http://www.cse.wustl.edu/~schmidt/win32-cv-1.html
168+
169+
See also
141170
*/
142171

143172
typedef CRITICAL_SECTION PyMUTEX_T;

0 commit comments

Comments
 (0)