time.h design issues

Markus Kuhn Markus.Kuhn at cl.cam.ac.uk
Sun Aug 29 12:59:18 UTC 1999


Paul Eggert wrote on 1999-08-29 11:04 UTC:
> True, but (1) in practice many people set the clock directly, without
> using adjtime, and (2) even adjtime can mess up benchmarks, the
> application domain that you proposed gettimeofday for.  With
> gettimeofday, one must make sure that nobody adjusts the system's
> notion of the time of day while you're doing benchmarks.  With
> TIME_MONOTONIC, you needn't worry about adjustments to the system
> clock.

The guaranteed continuity of TIME_MONOTONIC is one reason for the
existence of this separate clock type. This property is a very welcome
(and sometimes formally required!) assurance for the designer of
safety-critical system, who is not allowed to assume that the real-world
user knows, which type of resetting the clock is legal and which is not.
Embedded systems are in the real world often operated accidentally with
dates that are years off, and when people find out, they want to be able
to fix this immediately, without messing up safety-critical processes
while doing so. You all should have heard by know about the various
near-catastrophes that dumb Y2K tests have caused because the software
was not prepared to handle non-monotonicity. There definitely is a
requirement for at leat two clock types, one guaranteed to run always
and freely, the other providing a best-effort approximation of an
external scale such as say UTC, TAI, or whatever the available local
time happens to be.

But that is not all.

A second reason are small embedded systems (industrial automation
controllers (e.g., chemical and pharmaceutical industry) are frequently
quoted examples) that have no battery-powered clock and that get their
first opportunity to sync with an external time scale (if at all) only
considerable time after they booted. There are safety critical
applications that need guaranteed precise relative interval timing right
after system start-up, no matter whether the GPS antenna happens to be
pointing in the right direction etc., and TIME_MONOTONIC is intended for
these as well. This was an industrial requirement documented in the
POSIX process when the POSIX real-time extensions group considered
revising the clock definition to something not to far away from my
xtime_get.

And yes, these are real world safety and security requirements in
embedded realtime systems, in which the C API is very widely used today,
and where it is far from being satisfactory. Not every large-scale C
implementation underlies assumptions that might be perfectly valid for
Dan's desktop workstation.

"D. J. Bernstein" <djb at cr.yp.to> wrote on 1999-08-29:
> Who cares? Remember that the point of libtai is to support real
> programs, not to build an API in the sky.

Dan, did you ever work with an FAA certified run-time library and are
you familiar with the requirements expected from clock APIs in such
environments? I get the impression that you could learn a *lot* from
building "an API in the sky" ...

http://www.cl.cam.ac.uk/~mgk25/c-time/

Markus

-- 
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>




More information about the tz mailing list