From george at mvista.com  Fri Jul  9 00:40:29 2004
From: george at mvista.com (George Anzinger)
Date: Thu, 08 Jul 2004 17:40:29 -0700
Subject: Erroneous behavior
In-Reply-To: <1085667819.2156.150.camel@decugiss.frec.bull.fr>
References: <1085667819.2156.150.camel@decugiss.frec.bull.fr>
Message-ID: <40EDE97D.6000003@mvista.com>

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