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: 103376,cae92f92d6a1d4b1 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet 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: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Ada.Execution_Time Date: Mon, 27 Dec 2010 14:44:53 +0200 Organization: Tidorum Ltd Message-ID: <8nrg25FoucU1@mid.individual.net> 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> <1akm5muxu9zni.mu91b7pubqw0$.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net jNeYbdWVBQPrFPFVo943Awbn8o1AL2i7Pt+d98e8iUsDaQtJkb Cancel-Lock: sha1:WRVAsg0LPCc1KIAJz9oR2HGeI4c= User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) In-Reply-To: <1akm5muxu9zni.mu91b7pubqw0$.dlg@40tude.net> Xref: g2news2.google.com comp.lang.ada:17123 Date: 2010-12-27T14:44:53+02:00 List-Id: Dmitry A. Kazakov wrote: > On Sat, 25 Dec 2010 13:31:27 +0200, Niklas Holsti wrote: > >> Dmitry A. Kazakov wrote: >>> On Sat, 18 Dec 2010 23:20:20 +0200, Niklas Holsti wrote: >> ... >>>> The concept and measurement of "the execution time of a task" does >>>> become problematic in complex processors that have hardware >>>> multi-threading and can run several tasks in more or less parallel >>>> fashion, without completely isolating the tasks from each other. >>> No, the concept is just fine, >> Fine for what? For schedulability analysis, fine for on-line scheduling, >> ... ? > > Applicability of a concept is not what makes it wrong or right. I think it does. This concept, "the execution time of a task", stands for a number. A number is useless if it has no application in a calculation. I don't know of any other meaning of "wrongness" for a numerical concept. >> However, this is a side issue, since we are (or at least I am) >> discussing what the RM intends with Ada.Execution_Time, which must be >> read in the context of D.2.1, which assumes that there is a clearly >> defined set of "processors" and each processor executes exactly one >> task at a time. > > Why? Because RM D.14 uses terms defined in RM D.2.1, for example "executing". > Scheduling does not need Ada.Execution_Time, The standard schedulers defined in the RM do no not need Ada.Execution_Time but, as remarked earlier in this thread, one of the purposes of Ada.Execution_Time is to support the implementation of non-standard scheduling algorithms that may make on-line scheduling decisions that depend on the actual execution times of tasks. For example, scheduling based on "slack time". > it is the Ada.Execution_Time implementation, which needs some > input from the scheduler. We must be precise about our terms, here. Using terms as defined in http://en.wikipedia.org/wiki/Task_scheduling, Ada.Execution_Time needs input from the task *dispatcher* -- the part of the kernel that suspends and resumes tasks. It does not need input from the *scheduler*, which is the kernel part that selects the next task to be executed from among the ready tasks. The term "dispatching" is defined differently in RM D.2.1 to mean the same as "scheduling" in the Wikipedia entry. > How do you explain that CPU_Time, a thing about time sharing, appears in > the real-time systems annex D? You don't think that execution time is important for real-time systems? In my view, CPU_Time is a measure of "real time", so its place in annex D is natural. In your view, CPU_Time is not "real time", which should make *you* surprised that it appears in annex D. >> You have >> not given any arguments, based on the RM text, to support your position. > > I am not a language lawyer to interpret the RM texts. My argument was to > common sense. To me it seems that your argument is based on the difficulty (in your opinion) of implementing Ada.Execution_Time in some OSes such as MS Windows, if the RM word "time" is taken to mean real time. It is common sense that some OSes are not designed (or not well designed) for real-time systems. Even a good real-time OS may not support all real-time methodologies, for example scheduling algorithms that depend on actual execution times. >>>>> I am not a language lawyer, but I bet that an implementation of >>>>> Ada.Execution_Time.Split that ignores any CPU frequency changes >>>>> when summing up processor ticks consumed by the task would be >>>>> legal. >>>> Whether or not such an implementation is formally legal, that would >>>> require very perverse interpretations of the text in RM D.14. >>> RM D.14 defines CPU_Tick constant, of which physical equivalent (if >>> we tried to enforce your interpretation) is not constant for many >>> CPU/OS combinations. >> The behaviour of some CPU/OS is irrelevant to the intent of the RM. > > Nope, one of the killer arguments ARG people deploy to reject most > reasonable AI's is: too difficult to implement on some obscure platform for > which Ada never existed and never will. (:-)) Apparently such arguments, if any were made in this case, were not valid enough to prevent the addition of Ada.Execution_Time to the RM. Is your point that Ada.Execution_Time was accepted only because the ARG decided that the word "time" in RM D.14 should not be understood to mean real time? I doubt that very much... Surely such an unusual meaning of "time" should have been explained in the RM. >> As already said, an Ada implementation on such CPU/OS could >> use its own mechanisms for execution-time measurements. > > Could or must? Does GNAT this? I don't much care, it is irrelevant for understanding what the RM means. Perhaps the next version of MS Windows will have better support for measuring real task execution times; would that change the intent of the RM? Of course not. >> It seems evident to me that the text in D.14 must be interpreted using >> the concepts in D.2.1, "The Task Dispatching Model", which clearly >> specifies real-time points when a processor starts to execute a task and >> stops executing a task. To me, and I believe to most readers of the RM, >> the execution time of a task is the sum of these time slices, thus a >> physical, real time. > > If that was the intent, then I really do not understand why CPU_Time was > introduced in addition to Ada.Real_Time.Time / Time_Span. Because (as I understand it) different processors/OSes have different mechanisms for measuring execution times and real times, and the mechanism most convenient for CPU_Time may use a different numerical type (range, scale, and precision) than the mechanisms and types used for Ada.Real_Time.Time, Time_Span, and Duration. This is evident in the different minimum ranges and precisions defined in the RM for these types. Randy remarked on this earlier in this thread. >> And you still have not defined what you mean by "simulation time", and >> how you come there from the RM text. > > Simulation time is a model of real time a physical process might have under > certain conditions. Thank you. But I still do not see how your definition could be applied in this context, so we are back at the start of the post... :-) -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .