time.h design issues

Markus Kuhn Markus.Kuhn at cl.cam.ac.uk
Mon Aug 30 15:41:23 UTC 1999

Ulrich Drepper wrote on 1999-08-29 16:56 UTC:
> Well, then I hope you suggest an implementation for a monotonic time
> implementation.  Constraints are:
>   The underlying OS will not notify each running program about a sudden
>   clock change and itself does not provide a monotonic clock.

Which should definitely be changed soon for the GNU kernels.

An API that provides useful functionality does not become bad, just
because it would require some kernels to be upgraded. It just shows up a
deficiency in the current repertoire of OS functionality. And you are
surely well aware that the Kuhn/Eggert API drafts are certainly not the
only ones that require monotonic time:

The Real-Time Annex (especially section D.8) of the Ada95 standard for
instance requires a lot of useful OS functionality for safety-critical
applications (monotonic clock, priority ceiling locks, etc.), and Linux
for instance is still far away unfortunately from providing the required
functionality to implement this. (Embedded operating systems like QNX or
VxWorks are much more advanced here; please don't ask me about
Windows CE ;-)



And this is not just theoretical stuff, this is an API you use each time
you fly with a Boing 777. An Ada95 run-time system wouldn't get the
mandatory FAA certification if the time monotonicity weren't guaranteed
during the uptime of an aviation system. I hope that my API proposal is
good enough to allow a portable conforming implementation of Ada95's
section D.8 on top of it.

I hope you don't mind if I propose APIs with implementation options that
strech a bit the capabilities of underlying systems if practically
useful functionality is involved, because this will hopefully lead to
such problems being fixed eventually in the underlying systems.

Dan is certainly right in that TIME_MONOTONIC is not of use for "make",
because it does not guarantee monotonicity over certain types of system
events (e.g., hard reset, power-down, etc.) in systems without any
non-volatile state. I had thought of course early on about adding a
requirement for long-term monotonicity, but I didn't add it for two

  a) Defining a term such as "shutdown", "reboot", "cold
     start", "hard reset", "EMS sequence", "recovery", etc. in
     a sufficiently general way is difficult to get right for the broad
     range of systems that we want ISO C to be applicable to, and we
     talk also about systems that do not smell like Unix with an
     init process whose termination marks what a system reboot is.

  b) The definition would have been impossible to implement on systems
     without non-volatile memory, but there are a huge number of
     applications (practically most industrial controlling systems),
     that need monotonic time only between two hard resets.

  c) Finite integer arithmetic makes long-time monotonicity a somewhat
     hazardous project anyway, because once your clock gets by accident too
     close too 2**n (n = clock wordlength), you can never back off
     again and will be forced over the overflow. If we require the clock
     only to be monotonic for a certain maximum uptime (e.g., the 50 years
     mentioned in section D.8 of the Ada95 standard), we can always restart
     the entire system if we ever get too close to 2**n. A really
     guaranteed long-time monotonic clock on the other hand would
     have no way of recovering from a glitch that set it to 2**n-epsilon.
     So this would have been an example for a theoretically unimplementable
     specification. Safety system requirements also often specify, that
     systems have to be reset in a completely well-defined state on
     reset, which can mean that a monotonic clock has to be guaranteed
     to be 2**n-1 steps away from the next overflow.

So I decided to remove the requirement of long-term monotonicity from
TIME_MONOTONIC. This provides not what Dan's idealized "make" would
need, but it provides what many systems need, and there is no feasible
implementation I can think of that would really guarantee a long-term
monotonicity requirement as Dan seems to want. Except perhaps with
bignum arithmetic, but that seems like real overkill here, and it can
still accidentally overflow the memory during a glitch. (I said
"idealized make", because an alternative implementation that would
satisfy make's specific requirements is a clock with long-term
monotonicity and an overflow warning flag, and at each overflow of the
clock, this make semantics could automatically do a "make clean" or
equivalent action.)

I hope that this makes a bit clearer why I am so convinced that the idea
behind my TIME_MONOTONIC definition is already the most practical one
that you can get. It was strongly influenced, why what is commonly
required in the safety-critical systems literature and the Ada95
real-time annex is just one reference that I have handy.

If there is any interest, I would certainly be willing to discuss the
option of an overflow warning bit to TIME_MONOTONIC. I considered it
when I drafted the API, but dismissed it, because I wanted to have the
minimum complexity level that I though to be highgly practically
relevant. I also do not see monotonic clock overflow warning flags as a
common feature in embedded OS implementations, and "make" is one of the
very few applications that comes to mind, where this could be made good
use of.


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