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,61d8daec8bfa486e X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder.news-service.com!kanaga.switch.ch!news-zh.switch.ch!switch.ch!news.belwue.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: An Example for 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: <1fb06tjt2dy1y$.1tkafcv9oya2w.dlg@40tude.net> Date: Fri, 31 Dec 2010 15:14:57 +0100 Message-ID: <1sbf9ezy4cyrj$.vbev9pev30rq.dlg@40tude.net> NNTP-Posting-Date: 31 Dec 2010 15:14:54 CET NNTP-Posting-Host: 3dc57332.newsspool4.arcor-online.net X-Trace: DXC=aUTVVR=919[f8j24CD<3lP4IUK3L>K On Fri, 31 Dec 2010 13:05:06 +0000, Simon Wright wrote: > "Dmitry A. Kazakov" writes: > >> On Thu, 30 Dec 2010 18:51:30 -0500, BrianG wrote: >> >>> Since D.16 defines CPU_Time as if it were a numeric value, is it too >>> much to ask why a conversion to some form of numeric value wasn't >>> provided? >> >> But time is not a number and was not defined as if it were. It is the time >> differences which are numeric. RM D.14 defines differences of CPU_Time as >> Time_Span. Time_Span is numeric. > > This is certainly true. However, I remain surprised that .. even delving > back to v1.2 of the AI .. the proposer found it necessary to have this > type CPU_Time. The concept being looked for is the number of seconds > during which *this* task was executing, still sounds like a Duration > (OK, Time_Span if you must) to me. Yes, since the epoch is unambiguous: the task start. It does not make much sense to introduce execution time. Maybe a reason was that introducing clock returning time span or duration could be strange. > D14(13/2) says "For each task, the execution time value is set to zero > at the creation of the task."; however, zero is clearly not a value of > CPU_Time, so I don't know what is meant. Yes, Time_Of (0) seem to be the epoch. >> There is a direct correspondence between two, yet they are >> conceptually different things. > > I have no idea what's meant by CPU_Time, then! Seems to me it's a giant > bug waiting to happen. It's clear that the CPU_Time of one task is > incommensurate with the CPU_Time of another. Given that, what's it > _for_? That does not manifest any bug. Except that each task should have had its own CPU_Time type! Technically, it would be possible to inject an implicit declaration of a CPU_Time type in the declaration scope of each task. We could have a task-local "Standard/System" package encapsulating this and similar stuff. Though, nobody would care to do this. BTW, you could use CPU_Time as a simulation time within the task. E.g. you could have subtasks scheduled by the task. The scheduler would use the CPU_Time in order to activate/deactivate/re-schedule them, periodically according to the CPU_Time, rather than the system time. Happy New Year, -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de