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