Erroneous behavior
George Anzinger
george at mvista.com
Fri Jul 9 00:40:29 UTC 2004
Sebastien DECUGIS wrote:
> Hi,
>
> I've run into an issue with pthread_cond_timedwait() and
> clock_settime().
>
> 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
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
More information about the Phil-list
mailing list