Message133533
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) |
|
Date |
User |
Action |
Args |
2011-04-11 16:08:30 | neologix | set | recipients:
+ neologix, pitrou |
2011-04-11 16:08:30 | neologix | set | messageid: <1302538110.4.0.216338278823.issue11790@psf.upfronthosting.co.za> |
2011-04-11 16:08:29 | neologix | link | issue11790 messages |
2011-04-11 16:08:28 | neologix | create | |
|