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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,cae92f92d6a1d4b1 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Ada.Execution_Time Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH 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> Date: Wed, 29 Dec 2010 15:30:33 +0100 Message-ID: NNTP-Posting-Date: 29 Dec 2010 15:30:33 CET NNTP-Posting-Host: b1f2f452.newsspool2.arcor-online.net X-Trace: DXC=^e:LFLUX5CA78PK[oJ2ng@A9EHlD;3YcB4Fo<]lROoRA8kF 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. Windows rounds toward zero, which why you never get more load than 100%. But it is thinkable and expectable that some systems would round away from zero or to the nearest bound. So the statement holds only if you have A (maybe C) + a corresponding rounding. > - 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. In particular, task switching may be (and I think is) driven by the programmable timer interrupts. The real-time clock may be driven by the TSC. Since these two are physically different, unsynchronized time sources, the effect can be any. It is to expect a systematic error accumulated with the time. > 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 don't think RM can go into this. Not only because it would be not Ada's business, but because otherwise it would have to use some reference time. Ada does not have this, it intentionally refused to have it when introduced Ada.Real_Time.Time. The same arguments which were used then apply now. CPU_Time is a third time by default absolutely independent on the other two. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de