Kristján Valur Jónsson <krist...@ccpgames.com> added the comment: Thanks for your comments. The problem with _cond_timed_wait indicates that the timed wait code hadn't been thoroughly tested at the time of submission.
1) The InterlockedDecrement was left in by mistake. It must be removed 2) The LONG was argument was a vestige from trying to prevent the benign race condition with the _cond_timed_wait. As for the race condition, it is as follows: a) Thread A is waiting in _cond_timed_wait(), n_waiting == 1 b) The wait times out and it tries to acquire the lock to decrement n_waiting. This is a critical lock, because no one is waiting for the semaphore, yet n_waiting == 1 c) Thread B, that has the lock, calls _cond_signal(). It still sees n_waiting == 1 and does a ReleaseSemaphore. It then also decrements n_waiting, and n_waiting is now 0. The Semaphore count is now 1 d) Thread A finally gets the lock and decrements n_waiting. n_waiting is now -1. n_waiting has thus been decremented twice. But this is ok, since there was also an extra ReleaseSemaphore call and the semaphore count is now 1. The upshot of this is that this race condition is benign, and what happens is that the next time someone does _cond_wait(), the semaphore is reduced to 0, n_waiting goes to 0, and the thread passes right through. Thus, should this event happen, the only upshot of it is that one _cond_wait call will be ineffective. I'll upload a new patch with better explanation. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8411> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
