Charles-Francois Natali <neolo...@free.fr> added the comment: One possible cause for those intermittent failures is the preemtion of a thread while waiting on the condition:
def wait(self, timeout=None): 233 assert self._lock._semlock._is_mine(), \ 234 'must acquire() condition before using wait()' 235 236 # indicate that this thread is going to sleep 237 self._sleeping_count.release() 238 239 # release lock 240 count = self._lock._semlock._count() 241 for i in range(count): 242 self._lock.release() 243 <-- here 244 try: 245 # wait for notification or timeout 246 ret = self._wait_semaphore.acquire(True, timeout) For example, if the last thread/process is preempted after having released the condition's lock (and hence performed a up on the "sleeping" semaphore sooner in the "f" function) but before waiting on the condition's semaphore, since the main thread only waits 0.1s before locking the condition and performing a notify_all on it (it will proceed since all the threads performed an up on "sleeping"), only the threads already waiting on the condition will be woken up, this last thread won't be woken up, triggering a failure in this assertion 764 self.assertReturnsIfImplemented(0, get_value, woken) with woken.get_value() == 5 It's just a guess, but I'd suggest increasing the sleep before trying to signal the condition a bit: 762 # check no process/thread has woken up 763 time.sleep(10 * DELTA) ---------- nosy: +neologix _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11790> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
