This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Re: linuxthreads, POSIX 1003.1j and CLOCK_MONOTONIC
- From: Robert Bernecky <bernecky at sympatico dot ca>
- To: george anzinger <george at mvista dot com>,Ulrich Drepper <drepper at redhat dot com>
- Cc: Tom Gall <tom_gall at vnet dot ibm dot com>,Brian Kuschak <bkuschak at yahoo dot com>,<libc-alpha at sources dot redhat dot com>
- Date: Wed, 10 Jul 2002 23:17:37 -0400
- Subject: Re: Re: linuxthreads, POSIX 1003.1j and CLOCK_MONOTONIC
- Organization: Snake Island Research Inc
- Reply-to: bernecky at acm dot org
My apologies if this is old news, but it is a summary
of a very clean and simple design for timers:
The best implementation of clocks/timers I have yet seen
in the land of computers is the IBM S/370
"TOD clock" design. For the correct defn, you
should check the IBM "Principles of Operation" for
their current set of processors. In spite
of the fact that the clocks are a hardware design,
I think the design principles offer a lot to anyone
attempting to design an API for clocks and timers.
I'll try to summarize their characteristics here,
briefly:
Fundamental ideas:
- a clock or timer is represented as a 64-bit
value, relative to some epoch (I think they chose
around 1960, but the epoch is not too relevant).
The clock value ticks at, if I recall,
1 MHZ at the 2*10 bit. This permits higher resolution
by increasing the tick frequency, up to 2* 10 MHZ.
- 3 timer services are hardware-provided:
a. Time-of-day (TOD clock)
b. Clock comparator
c. Processor timer
The TOD clock provides the current 64-bit time value
to a process, with the following characteristics:
- the clock is generally maintained in UTC
(this is an OS thing, not a hardware thing)
- the OS maintains an offset from UTC, and
the equivalent of glibc integrates the
offset, if desired, into the result.
- The TOD clock NEVER returns the same value twice,
and is guaranteed monotonically increasing.
The latter facilitates using the TOD clock
as a way to hand out "laundry tickets",
or other unique identifiers.
- keeping the hardware timer in UTC allows multiple
OSs running under a VM environment to run any
timezone they want.
- returning the entire timestamp as an atomic
value ensures that there are no race conditions
between date sampling and time-of-day sampling.
This is a problem with certain APIs that require
you to sample time-of-day and date as separate
calls to the OS, with the possibility of rollover
of dates between the calls.
The clock comparator is a 64-bit "register" that
contains a TOD value which will cause an interrupt
whenever its value is less than the TOD value
(which increments monotonically at the above
1MHZ or better rate). This has two virtues:
First, an interval time queue can maintain
real-time values in its queue entries, and
not have to worry about race conditions or
clock slippage between the real time and the
expiry time. The queue manager can simply
jam the next queue value into the clock
comparator and be done with it. Of course,
it might make more sense to post all entries
that are known to be in the past first, but
that's a frill for performance only.
The key thing is that ANY event that has
already expired will be treated properly by
the hardware.
The processor timer is like the TOD clock, but it
increments only when a specific task is running.
Hence, it offers high-resolution CPU time
measurement of active processes. The idea of
GHZ processors with 100Hz timer facilities is silly,
IMO.
Historical note of no importance otherwise:
Back in the dark ages, when the alternative was the 300hz
"interval timer", switching to the processor timer
increased our monthly billing on a 1000-user timesharing
system by 42-billion pazoozas, because we threw
away too many 1/300ths of a second the old way.
Bob
> From: george anzinger <george@mvista.com>
> Date: 2002/07/10 Wed PM 07:24:57 EDT
> To: Ulrich Drepper <drepper@redhat.com>
> CC: Tom Gall <tom_gall@vnet.ibm.com>, Brian Kuschak <bkuschak@yahoo.com>,
> libc-alpha@sources.redhat.com
> Subject: Re: linuxthreads, POSIX 1003.1j and CLOCK_MONOTONIC
>
> Ulrich Drepper wrote:
> >
> > On Wed, 2002-07-10 at 12:19, Tom Gall wrote:
> >
> > > We are planning on getting this implemented in the next couple of
> > > months. Basically we're working on getting the rest of the
> > > POSIX Realtime Options that are currently NOT implemented, implemented.
> >
> > And this should in some way be positive? That you even think about
> > implementing CLOCK_MONOTONIC shows that you didn't even try to
> > understand the issues. This clock cannot be implemented without
> > breaking the ABI.
> >
> What is needed is the high-res-timers patch in the kernel,
> which provides kernel support for CLOCK_MONOTONIC as well as
> other nice things. We are trying to get this into the 2.5
> kernel.
>
> On the other hand, we need the linux threads package to
> support "thread groups" to help sort out the signal issues
> as well as some of the thread creation on timer expire
> stuff.
>
> I would caution against doing much more in glibc with out
> the kernel support. The problem is that all this needs to
> be supported AND some of what ends up in glibc with out
> kernel support will be a "wort" in glibc after kernel
> support just to support a feature that few folks use or
> need.
> --
> George Anzinger george@mvista.com
> High-res-timers:
> http://sourceforge.net/projects/high-res-timers/
> Real time sched: http://sourceforge.net/projects/rtsched/
> Preemption patch:
> http://www.kernel.org/pub/linux/kernel/people/rml
>
Robert Bernecky Snake Island Research Inc.
bernecky@acm.org 18 Fifth Street, Ward's Island
+1 416 203 0854 Toronto, Ontario M5J 2B9 Canada
http://www.snakeisland.com