time.h design issues
Markus.Kuhn at cl.cam.ac.uk
Tue Aug 31 14:22:51 UTC 1999
"D. J. Bernstein" wrote on 1999-08-30 23:02 UTC:
> Markus Kuhn writes:
> > no feasible implementation I can think of that would really guarantee
> > a long-term monotonicity requirement as Dan seems to want.
> Long-term monotonicity is the natural state of affairs. Clocks increase
> over time, see? It would be trivial for an OS kernel to guarantee this,
> even through reboots, given the battery-powered clocks already available
> in almost all computers.
> > 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.
> But your API obviously flunks this test.
> You keep talking about safety-critical real-time applications. I have
> news for you: safety-critical real-time applications need tick counters
> that _=08w_=08o_=08r_=08k. Your TIME_MONOTONIC is allowed to fail at any
The reason for why I haven't required TIME_MONOTONIC to be always
available is that there are currently operating systems that are not
able to provide anything like TIME_MONOTONIC. See Ulrich's posting. I
want to enable Ulrich to let glibc say on Linux 2.2 that TIME_MONOTONIC
is not available.
The reason why I allowed TIME_MONOTONIC to fail even when it has worked
before in the same process is in order to allow an environment to signal
to an application that there has been an unavoidable TIME_MONOTONIC
discontinuity. The simplest example is a laptop with power management
function enabled, where the Pentium can stop its clock and thereby also
the TSC. Another more interesting example is an ATM security module
using the DS5002FP processor with a battery stop enabled, or a DS1954
iButton that has been pulled off the socket prematurely by the user,
which must not interrupt a transaction, but where it is security
critical that the application is informed about the fact that the system
can't provide any data on how long the full transaction has lasted, such
that a secure path can be followed (in a crypto application this means
usually to abort a transaction and invite a restart with new nonces). As
I said, just a real world example.
My API proposal does not guarantee that anything is available. I don't
want to make such restrictions, because I want the API to be very widely
implementable, and at the same time, I want it to make possible for
implementors to use the API such that it never has to lie to the
application. I just don't like APIs that lie to the application.
Offering additional guarantees is the task of the documentation that
comes with the API. It is perfectly possible to make this documentation
also available as a compile-time or run-time parameter to the software,
like we have in the form of the POSIX sysconf() mechanism. If you want
additional useful requirements such as "TIME_MONOTONIC is always
available", then please send me a list of these and I'd be happy to
define for you a TIME_MONOTONIC_IS_ALWAYS_AVAILABLE flag for sysconf()
and whatever else you need as guarantee flags from the implementation.
An implementation would not be allowed to set this flag on e.g. a laptop
where APM functions are active or could be easily activated, or on
crypto modules, where power-downs are required to only pause but never
abort protocol transactions.
The Ada95 D.8 spec is actually much more generous, because it has
only requirements for the documentations that come with the API:
"The implementation shall document the properties of the underlying time
base used for the clock and for type Time, such as the range of values
supported and any relevant aspects of the underlying hardware or
operating system facilities used. [...] The implementation shall
document any aspects of the the external environment that could
interfere with the clock behavior as defined in this clause."
So the authors of the Ada95 real-time annex followed here as well the
principle: We provide the implementor of the environment all the tools
necessary to get it really right, but whether it was really done right,
the user has to verify by reading the documentation. We require that the
documentation talks about these things honestly and in sufficient
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