Author neologix
Recipients neologix, pitrou
Date 2011-04-11.16:08:28
SpamBayes Score 1.74878e-06
Marked as misclassified No
Message-id <>
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()'
   236         # indicate that this thread is going to sleep
   237         self._sleeping_count.release()
   239         # release lock
   240         count = self._lock._semlock._count()
   241         for i in range(count):
   242             self._lock.release()
<-- 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)
Date User Action Args
2011-04-11 16:08:30neologixsetrecipients: + neologix, pitrou
2011-04-11 16:08:30neologixsetmessageid: <>
2011-04-11 16:08:29neologixlinkissue11790 messages
2011-04-11 16:08:28neologixcreate