george at mvista.com
Fri Jul 9 00:40:29 UTC 2004
Sebastien DECUGIS wrote:
> I've run into an issue with pthread_cond_timedwait() and
> The basics of my attached test is:
> clock_gettime() -> time in ts
> create a thread
> [thread] pthread_cond_timedwait() with timeout = ts + 20sec
> [main]clock_settime() with new ts > timeout
> In this situation, the POSIX IEEE 1003.1 (2004) standard states that the
> behavior of the thread should be as if the time had runned out (please
> refer to the clock_settime() reference, §4). But when I run my test with
> a fresh nptl (cvs from monday), I have to wait for the timeout as if the
> clock had not been changed. Please note that even if I signal the
> condition, I get the ETIMEDOUT error code return (which is normal).
> I think this is due to the absolute timeout parameter being tranformed
> into a relative timeout in the pthread_cond_timedwait routine. Is this
> operation unavoidable?
> Maybe a workaround would be to wake every threads waiting (in
> pthread_cond_timedwait) on a given clock when this clock is set forward.
> At worst, it results in a legal spurious wakeup, if the time out is not
> expired. Please let me know if this is a kernel issue?
Yes, this is a kernel issue. The abs timers were not doing the right thing with
clock setting. A patch was submitted and, I think, accepted. At this point I
think it is in the BK kernels, not yet in the 2.6.x kernel. If I remember the
numbers right, it should be in the 2.6.8 kernel.
George Anzinger george at mvista.com
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
More information about the Phil-list