Re: pthread_cond_timedwait/posix timers

[george anzinger <george at mvista dot com>]

Amos Waterland wrote:
> 
> On Thu, Aug 08, 2002 at 12:07:39PM -0700, H. J. Lu wrote:
> > On Wed, Aug 07, 2002 at 06:28:24PM +0000, Amos Waterland wrote:
> > > There are some problems with the POSIX timer and condition wait
> > > implementation in glibc.  I am very interested in fixing them, but think
> > > that it would be best to have a discussion over the list first.
> >
> > FYI, those are academic to me. I have a real issue to solve:
> 
> Thanks for your reply.
> 
> > http://sources.redhat.com/ml/libc-alpha/2002-02/msg00057.html
> >
> > That is why I added the relative timeout interface. In my case, I
> > really don't care how precise it is. But it should never wait for
> > a few years unless it is really intended :-).
> 
> Agreed.  But the standard implies that pthread_cond_timedwait() *should*
> wait for 20 years if it is based upon CLOCK_REALTIME.

As currently implemented, the kernel can handle a timer that
is "max long" jiffies from now.  A timer further out has to
be either truncated back to this time or kicked out as an
error.  After writing several test programs to verify
high-res-timers, I have come to the conclusion that the best
approach is to kick such requests out as an error.

This would not help the 20 years example if it were changed
to 200 days, but then, CLOCK_MONOTONIC should be used in
this case.  (No, CLOCK_MONOTONIC is not in glibc, but it is
in high-res-timers.)
> 
> Having interval timers expire at incorrect times is not really just an
> academic issue.
> 
> The reason I wanted to ask people on the list is that I don't see a
> clean way to solve either problem in userspace.  We could make
> pthread_cond_timedwait() respect CLOCK_REALTIME with a ugly nanosleep()
> poll approach, and could use the solution for relative timers I
> mentioned in my previous email, but both will have performance/ugliness
> problems.
> 
> As mentioned by Drepper, Azinger, Bernecky, and Kylheku, probably the
> only way to fix these problems correctly is to have a real
> clock_nanosleep() provided by the kernel.  Unless anybody has a bright
> idea, I am going to defer further work on these issues until the
> high-res-timers go into the kernel.

The work that would advance high-res-timers in glibc is the
adoption of the kernel's thread groups by linux threads. 
This would allow the kernel to understand that timers belong
to processes and not threads.  With out thread groups, the
kernel is rather, well, blind on this issue.


-- 
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