Condition.wait timeout fails when system clock changes

[hashstat]

BPO	1607041
Nosy	@rhettinger

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2007-04-11.17:19:46.000>
created_at = <Date 2006-12-01.18:45:29.000>
labels = ['library']
title = 'Condition.wait timeout fails when system clock changes'
updated_at = <Date 2007-04-11.17:19:46.000>
user = 'https://bugs.python.org/hashstat'

bugs.python.org fields:

activity = <Date 2007-04-11.17:19:46.000>
actor = 'rhettinger'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2006-12-01.18:45:29.000>
creator = 'hashstat'
dependencies = []
files = []
hgrepos = []
issue_num = 1607041
keywords = []
message_count = 6.0
messages = ['30724', '30725', '30726', '30727', '30728', '30729']
nosy_count = 3.0
nosy_names = ['rhettinger', 'exarkun', 'hashstat']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1607041'
versions = ['Python 2.4']

[hashstat]

If the system clock is adjusted after Condition.wait is called with a timeout, the timeout does not expire as expected. This appears to be due to the threading.Condition class using the system clock to calculate the timeout expiration without taking system clock changes into account. Let me illustrate this with an example:

   import threading

   c = threading.Condition()
   c.acquire()
   try:
      ...
      c.wait(3600.0)
      ...
   finally:
      c.release()

Let's say the above snippet is executed at 08:00. Assuming the condition is never notified, the timeout should expire somewhere close to 09:00. At 08:30 someone notices that the clock is an hour fast and sets it back to 07:30. The timeout still expire around 09:00 causing a wait of 2 hours instead of the requested 1 hour.

Now let's say instead that the clock was moved ahead to 09:30 at 08:30. The timeout would expire immediately after only a 30 minute wait.

[exarkun]

Why should it work that way?

c.wait(3600) doesn't say "wait until 0900", it says "wait 60 minutes".

If you want c.waitUntil(9 oclock), maybe that would be a good API addition, but it definitely should be a separate method.

[hashstat]

Apparently my description wasn't as clear as I thought. I don't care about the clock times in the example. They were only used to illustrate the point. What I do care about is that if a use c.wait(3600) ("wait 60 minutes"), then my thread should wake up in roughly 60 minutes without regard to changes in the system clock.

With the current Condition implementation, no matter what timeout is used, setting the system clock ahead reduces or eliminates the wait while setting the system clock back increases the wait. So if the clock is set back one hour in the middle of a 1 microsecond wait (c.wait(1)), wait will return in an hour and 1 microsecond. Is this the way it should work?

[hashstat]

I submitted patch# 1607149 to add checking for clock variations in the wait method when called with a timeout.

[exarkun]

Yes, I misunderstood. Please disregard my comments. :)

[rhettinger]

I don't think this is the right thing to do. Detecting clock changes is tricky (all you can do is detect backward movement). Then, deciding what to do about it also involves a certain amount of guesswork (at how much the time changed and what the user really wants to occur). Also, changing clocks may affect many parts of the system (log entries being out of order, etc) and it is not entirely clear what the interactions should be with the Condition timeout. IOW, when the clock changes, you've likely got bigger problems. Refuse the temptation to guess.