[issue11790] transient failure in test_multiprocessing.WithProcessesTestCondition

[Charles-Francois Natali]

Charles-Francois Natali <neologix at 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 <report at bugs.python.org>
<http://bugs.python.org/issue11790>
_______________________________________