This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: pthread_cond_timedwait/posix timers
- From: george anzinger <george at mvista dot com>
- To: Kaz Kylheku <kaz at ashi dot footprints dot net>
- Cc: Amos Waterland <apw at us dot ibm dot com>, libc-alpha at sources dot redhat dot com
- Date: Thu, 08 Aug 2002 10:04:48 -0700
- Subject: Re: pthread_cond_timedwait/posix timers
- Organization: Monta Vista Software
- References: <Pine.LNX.4.44.0208080850060.7022-100000@ashi.FootPrints.net>
Kaz Kylheku wrote:
>
> On Wed, 7 Aug 2002, Amos Waterland wrote:
> > 1.1 There is a race condition in __pthread_timedsuspend_new(), where if the
> > thread is preempted between its __gettimeofday() and __libc_nanosleep()
> > calls, pthread_cond_timedwait() will return after the desired time.
>
> It's not possible for a function to not return after the desired time,
> since it has to execute instructions after it is woken up. It may be
> preempted at any time before it returns.
>
> We use nanosleep() with a relative timeout because the kernel doesn't
> give us a clock_nanosleep() that could be made to sleep absolutely.
>
> This is rather ironic, because sleeps in the kernel are based on
> absolute timeouts! So the relative timeout in nanosleep() has to be
> converted back to an absolute jiffy count.
>
> Fixing these kinds of issues requires kernel support.
And the high-res-timers patch is an attempt to do so. At
this time I am adding support for clock changes to this
patch. It is hoped that the patch will be accepted in the
2.5 kernel.
It should be noted, however, that clock changes that are
made by ntp code are a bit of a tough nut to crack. The
best solution would be to change the rate of the system
"jiffie" clock rather than "slipping" the wall clock WRT the
"jiffie" clock as is done now. Unfortunately this requires
work for each platform...
--
George Anzinger george@mvista.com
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml