"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 moment.
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 detail. Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>