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 ;-) See: http://wuarchive.wustl.edu/languages/ada/userdocs/docadalt/rm95/d.htm 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 reasons: 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 -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>