From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,cae92f92d6a1d4b1 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "(see below)" Newsgroups: comp.lang.ada Subject: Re: Ada.Execution_Time Date: Wed, 29 Dec 2010 16:19:13 +0000 Message-ID: References: <4d05e737$0$6980$9b4e6d93@newsspool4.arcor-online.net> <1wmsukf0wglz3$.odnzonrpayly.dlg@40tude.net> <6n1c5myuf2uz$.10jl3ln7il3aq.dlg@40tude.net> <8n0mgnFv2sU1@mid.individual.net> <1n3o55xjdjr9t.1u33kb75y2jfl$.dlg@40tude.net> <8n1142Fto2U1@mid.individual.net> <1o5cbm4b1l20d$.19winbma6k5qw.dlg@40tude.net> <8n4mskF7mmU1@mid.individual.net> <8nm30fF7r9U1@mid.individual.net> <8o0p0lF94rU1@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: individual.net FLsN81GEEMX17C5XXDOoegBfm1DH4ttylQCjGdv+1bPe1bvbgD Cancel-Lock: sha1:OueNhhBtC94RjOzut9Pi0GjN6fc= User-Agent: Microsoft-Entourage/12.28.0.101117 Thread-Topic: Ada.Execution_Time Thread-Index: AcundCF7POBmRPQW/ECWdftBmwpkBw== Xref: g2news2.google.com comp.lang.ada:17201 Date: 2010-12-29T16:19:13+00:00 List-Id: On 29/12/2010 14:30, in article aooml6t0ezs4.4srxtfm9z00r.dlg@40tude.net, "Dmitry A. Kazakov" wrote: > On Wed, 29 Dec 2010 14:48:20 +0200, Niklas Holsti wrote: > >> Dmitry has agreed with some of my statements on this point, for example: >> >> - A task cannot accumulate execution time at a higher rate than real >> time. For example, in one real-time second the CPU_Time of a task cannot >> increase by more than one second. > > Hold on, that is only true if a certain model of CPU_Time measurement used. > There are many potential models. The one we discussed was the model A: > > Model A. Get an RTC reading upon activation. Each time CPU_Time is > requested by Clock get another RTC reading, build the difference, add the > accumulator to the result. Upon task deactivation, get the difference and > update the accumulator. > > This is a very strong model. Weaker models: > > Model A.1. Get RTC upon activation and deactivation. Update the accumulator > upon deactivation. When the task is active CPU_Time does not change. > > Model B. Use a time source different from RTC. This what Windows actually > doest. > > Model B.1. Like A.1, CPU_Time freezes when the task is active. > > Model C. Asynchronous task monitoring process > > ... > Note that in either model the counter readings are rounded. ... > >> - If only one task is executing on a processor, the execution time of >> that task increases (or "could increase") at the same rate as real time. > > This also may be wrong if a B model is used. ... > >> The question is how much meaning should be read into ordinary words like >> "time" when used in the RM without a formal definition. > > Time as physical concept is not absolute. There is no *the* real time, but > many real times and even more unreal ones. ... I hope we can agree that Ada is defined "sensibly". >From this I deduce that the intent for CPU_Time is that it be a useful approximation to the sum of the durations (small "d") of the intervals of local inertial-frame physical time in which the task is in the running state. It seems to me that the only grey area is the degree of approximation that is acceptable for the result to be "useful". Dmitri raises some devils-advocate issues around that. Some of them might be considered to be dismissed by the assumption of sensible definition. Others might not be so clear. Perhaps the ARG consider these to be issues of implementation quality rather than semantics. -- Bill Findlay with blueyonder.co.uk; use surname & forename;