I agree with hashstat that this is a bug. The application specified a time-out as a duration, not as a point in time. A duration is independent of what the clock says: 10s are 10s, even if the clock gets adjusted.

The proper fix would be that locks themselves get a time-out, so that Condition.wait could pass the timeout on to waiter.acquire. For thread_nt.h, the timeout could get passed to WaitForSingleObject; for thread_pthread, it could get passed to sem_timedwait (if available). Not sure about the other threading libraries.

In any case, *this* issue needs to stay closed. If anybody can provide an alternative solution, please submit a new issue.