* Re: Ada 95 Timers: Any Alternatives Available, Storage, Efficiency, Reliability, Accuracy, Et Cetera Issues?
@ 2019-05-30 16:20 6% ` Dmitry A. Kazakov
0 siblings, 0 replies; 18+ results
From: Dmitry A. Kazakov @ 2019-05-30 16:20 UTC (permalink / raw)
On 2019-05-30 17:34, Niklas Holsti wrote:
> On 19-05-30 16:57 , Felix_The_Cat@gmail.com wrote:
>>
>> What are the limitations of the "with Timer;" in Ada 95?
>
> Not understood. There is no standard "package Timer" in Ada 95 (nor
> other Ada standards, AFAIK).
It looks that the OP meant Ada.Execution_Time.Timers.
>> I want to simply do something in the Ada code when the timer
>> counts down to 0.
>
> That sounds like some HW timer. Normally you would not use those
> directly, but instead use the "delay" or "delay until" statements, to
> wait until the actual time when something should be done, and let the
> compiler and run-time system handle the HW timers.
Right, alternatives could also be timed entry call (9.7.2) and delay
alternative of selective accept (9.7.1).
As for limitations of Ada.Execution_Time.Timers they are from the SW
design POV. Scheduled actions usually interact with the program logic,
the states of program objects, the context of the task performing these
actions. Ada.Execution_Time.Timers are too low-level for a that.
The intended use of Ada.Execution_Time.Timers is for something quite
decoupled from the program itself, e.g. I can imagine a system health
monitoring based on Ada.Execution_Time.Timers.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 6%]
* Re: Access parameters and accessibility
2014-12-17 2:02 3% ` Adam Beneschan
@ 2014-12-17 23:18 0% ` Randy Brukardt
0 siblings, 0 replies; 18+ results
From: Randy Brukardt @ 2014-12-17 23:18 UTC (permalink / raw)
"Adam Beneschan" <adambeneschan@gmail.com> wrote in message
news:eea29e4c-921a-467c-8007-80e80eda3507@googlegroups.com...
On Tuesday, December 16, 2014 11:46:59 AM UTC-8, Michael B. wrote:
...
>I'm sure Randy was being tongue-in-cheek when he said "get better
>libraries".
Ahh, no.
...
>For one thing, you'd have to get better libraries than the libraries Ada
>provides,
>because Ada defines some subprograms with anonymous access
>parameters--namely
>Ada.Tags.Generic_Dispatching_Constructor, Ada.Execution_Time.Timers.Timer,
>and >Read|Write_Exception_Occurrence in Ada.Exceptions. Also, the stream
>attribute
>subprograms ('Read, 'Write, etc.) all have anonymous access parameters, and
>you
>have to *write* a subprogram that has an anonymous access parameter in
>order to
>use it as the stream subprogram for a type. Quelle horreur!
Yup. With the exception of timers, all of the others stem directly from the
mistake of using an anonymous access for streams. And *that* stems from the
mistake of not allowing "in out" parameters for functions (as Input is a
function).
Ergo, in Ada 2012 you would write those as "in out Root_Stream_Type'Class".
And one should think of them as exactly that. (It's too late to fix this
mistake, sadly.)
In the case of Timer, (a) no one ever uses this feature, and (b) I have no
idea why this just isn't
type Timer (T : Ada.Task_Identification.Task_Id) is tagged limited private;
I have no idea who has an aliased Task_Id laying around anyway. That seems
amazingly hard to use for no value whatsoever. I suspect it was something
else originally and it never got changed sensibly.
>Anyway, I think you can avoid defining new subprograms that take anonymous
>access
>parameters (except where needed for streams, or for
>Generic_Dispatching_Constructor)
>and not add to the problem, but I don't see any value in avoiding existing
>libraries.
Well, if you could tell a-priori if "access" was used as a stand-in for "in
out", then it would be OK. In that case, the only use of the "access" is to
dereference it.
But it if is actually used as an access type (with the access value being
copied somewhere), then you have trouble (with random Program_Errors and a
need to avoid passing local objects). It's possible in Ada 2012 to write a
precondition for this case, but of course that's not required (and surely is
not found in existing libraries), so the possibility doesn't help much.
Since you can't tell these cases apart (and the first is never necessary in
Ada 2012 anyway, with the possible exception of foreign conventions), it's
best to just avoid the feature. Especially as "access" is more expensive
than "in out" because of the dynamic accessibility checking overhead (which
exists regardless of whether it is ever used). Libraries should reflect this
(moreso as Ada 2012 gets adopted more).
Randy.
^ permalink raw reply [relevance 0%]
* Re: Access parameters and accessibility
@ 2014-12-17 2:02 3% ` Adam Beneschan
2014-12-17 23:18 0% ` Randy Brukardt
0 siblings, 1 reply; 18+ results
From: Adam Beneschan @ 2014-12-17 2:02 UTC (permalink / raw)
On Tuesday, December 16, 2014 11:46:59 AM UTC-8, Michael B. wrote:
> > Besides, I agree with the others that it has nothing to do with OOP. Claw
> > only uses anonymous access parameters to get the effect of in out parameters
> > in functions (which isn't a problem with Ada 2012 anyway), and as Dmitry
> > noted, it doesn't work very well. Anonymous access parameters: just say no!!
>
> How can I avoid them when they are heavily used in so many libraries?
> E.g. GtkAda: I just looked into some arbitrary .ads files from Gnat GPL
> 2014 (glib-string.ads, glib-object.ads and gdk-event.ads) and found
> examples of the usage of anonymous access parameters.
> You could argue that this is bad design, but rewriting all this code is
> not really an option for me.
> And compared to writing GUIs in plain C it seems to be the lesser of two
> evils.
I don't see how it could be a problem if you *use* a subprogram that requires an anonymous access parameter. You can pretty much just pass in an object of any matching named access type, or 'Access (or 'Unchecked_Access) of a matching object. You don't need to create any new anonymous access types in order to do so.
I'm sure Randy was being tongue-in-cheek when he said "get better libraries". For one thing, you'd have to get better libraries than the libraries Ada provides, because Ada defines some subprograms with anonymous access parameters--namely Ada.Tags.Generic_Dispatching_Constructor, Ada.Execution_Time.Timers.Timer, and Read|Write_Exception_Occurrence in Ada.Exceptions. Also, the stream attribute subprograms ('Read, 'Write, etc.) all have anonymous access parameters, and you have to *write* a subprogram that has an anonymous access parameter in order to use it as the stream subprogram for a type. Quelle horreur! Anyway, I think you can avoid defining new subprograms that take anonymous access parameters (except where needed for streams, or for Generic_Dispatching_Constructor) and not add to the problem, but I don't see any value in avoiding existing libraries.
-- Adam
^ permalink raw reply [relevance 3%]
* Re: Ada.Execution_Time
@ 2011-01-01 15:54 3% ` Simon Wright
0 siblings, 0 replies; 18+ results
From: Simon Wright @ 2011-01-01 15:54 UTC (permalink / raw)
"Randy Brukardt" <randy@rrsoftware.com> writes:
> Your discussion of real-time scheduling using this still seems to me
> to be more in the realm of academic exercise than something
> practical. I'm sure that it works in very limited circumstances, but
> those circumstances are getting less and less likely by the year.
Sounds as if you don't agree with the !problem section of AI-00307?
The first paragraph says that measurement/estimation is important, and
that measurement is difficult [actually, I don't see this; _estimation_
is hard, sure, what with pipelining, caches etc, but _measurement_?]
The second paragraph says that in a hard real time system you ought to
be able to monitor execution times in order to tell whether things have
gone wrong. Hence Ada.Execution_Time.Timers.
The third paragraph talks about fancy scheduling algorithms. This is the
point at which I too start to wonder whether things are getting a bit
academic; but I have no practical experience of the sort of real-time
systems under discussion. We merely have to produce the required output
within 2 ms of a program interrupt; but the world won't end if we miss
occasionally (not that we ever do), because of the rest of the system
design, which has to cope with data loss over noisy radio channels.
The last paragraphs call up the Real-Time extensions to POSIX (IEEE
1003.1d, after a lot of googling) as an indication of the intention.
^ permalink raw reply [relevance 3%]
* Re: An Example for Ada.Execution_Time
2010-12-28 2:31 6% ` BrianG
2010-12-28 13:43 0% ` anon
@ 2010-12-29 3:10 0% ` Randy Brukardt
1 sibling, 0 replies; 18+ results
From: Randy Brukardt @ 2010-12-29 3:10 UTC (permalink / raw)
"BrianG" <briang000@gmail.com> wrote in message
news:ifbi5c$rqt$1@news.eternal-september.org...
...
> I asked for:
> >> An algorithm comparison program might look like:
> >>
> >> with Ada.Execution_Time ;
> >> with Ada.Execution_Time.Timers ;
> >Given the below program, please add some of the missing details to
> >show how this can be useful without also "with Ada.Real_Time".
> >Neither Execution_Time or Execution_Time.Timers provides any value
> >that can be used directly.
This seems like a totally silly question. There are a lot of well-designed
packages in Ada that don't do anything useful without at least one or more
other packages. Indeed, if you consider "Standard" to be a separate package
(and it is), there are hardly any packages that *don't* require some other
package to be useful.
More to the point, you probably need Ada.IO_Exceptions to use
Ada.Directories effectively (use of any package without error handling is
toy use); Ada.Streams.Stream_IO require use of Ada.Streams (a separate
package, which you will need separate use clauses for even if you get it
imported automatically); Ada.Strings.Maps aren't useful for anything unless
you combine them with one of the string handling packages, and so on.
Perhaps you would have been happier if Ada.Execution_Time had been a child
of Ada.Real_Time (exactly as in the string case), but this wouldn't change
anything.
The odd thing is that Duration is defined in Standard, rather than some more
appropriate package. Giving this some sort of religious importance is beyond
silly...
Randy.
^ permalink raw reply [relevance 0%]
* Re: Ada.Execution_Time
2010-12-28 14:46 0% ` Ada.Execution_Time Niklas Holsti
@ 2010-12-28 15:42 0% ` Dmitry A. Kazakov
0 siblings, 0 replies; 18+ results
From: Dmitry A. Kazakov @ 2010-12-28 15:42 UTC (permalink / raw)
On Tue, 28 Dec 2010 16:46:20 +0200, Niklas Holsti wrote:
> And you seem to forget that Ada.Execution_Time may be implemented by
> reading a real-time clock. As has been said before.
Only if you have control over the OS or else can hook on task switches. I
think it is doable under VxWorks. But I doubt that AdaCore would do this.
> Dmitry:
>>>> I don't
>>>> care how much processor time my control loop takes so long it manages to
>>>> write the outputs when the actuators expect them.
> Niklas:
>>> You should care, if the processor must also have time for some other
>>> tasks of lower priority, which are preempted by the control-loop task.
> Dmitry:
>> Why? It is straightforward: the task of higher priority level owns the
>> processor.
>
> Do you mean that your system has only one task with real-time deadlines,
> and no CPU time has to be left for lower-priority tasks, and no CPU time
> is taken by higher-priority tasks? Then scheduling is trivial for your
> system and your system is a poor example for a discussion about scheduling.
Right, a real-time system is usually a bunch of tasks activated according
to their priority levels. This is why I doubted that Ada.Execution_Time
might be useful there.
> Niklas:
>>> For example, assume that the computation in a control algorithm consists
>>> of two consecutive stages where the first stage processes the inputs
>>> into a state model and the second stage computes the control outputs
>>> from the state model. Using Ada.Execution_Time or
>>> Ada.Execution_Time.Timers the program could detect an unexpectedly high
>>> CPU usage in the first stage, and fall back to a simpler, faster
>>> algorithm in the second stage, to ensure that some control outputs are
>>> computed before the deadline.
> Dmitry:
>> No, in our systems we use a different schema.
>
> So what? I said nothing (and know nothing) about your system, any
> resemblance is coincidental. And there can be several valid schemas.
No, the point was rather that your schema is not typical for a real-time
system.
>> Consider a system with n-processors. The execution
>> time second will be 1/n of the real time second.
>
> No. If you have n workers digging a ditch, you must pay each of them the
> same amount of money each hour as if you had one worker. So the "digging
> hour" is still one hour, although the total amount of work that can be
> done in one hour is n digging-hours. You are confusing the total amount
> of work with the amount of work per worker.
The ditch has 10 digging hours, this is a virtual time, which can be 1 real
hour if I had 10 workers or 26 hours if I have only one (26 = 24(8) + 2, 8
hours per day). With one worker it can even be 26 + 48 if he starts Friday,
or even more if she takes a leave for child rearing (:-)).
The sum of working hours is a measure of work. It is not a measure of time.
Time = Work / Power
You can use it to estimate the real time required to complete the work ...
or just re-read the The Mythical Man-Month... (:-))
> With n processors the system can do n seconds worth of execution in one
> real-time second. But each processor still executes for one second. And
> as I understand the Ada task dispatching/scheduling model, one task
> cannot execute at the same time on more than one processor, so one task
> cannot accumulate more than one second of execution time in one second
> of real time.
Yes.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Re: Ada.Execution_Time
2010-12-27 21:53 0% ` Ada.Execution_Time Dmitry A. Kazakov
@ 2010-12-28 14:46 0% ` Niklas Holsti
2010-12-28 15:42 0% ` Ada.Execution_Time Dmitry A. Kazakov
0 siblings, 1 reply; 18+ results
From: Niklas Holsti @ 2010-12-28 14:46 UTC (permalink / raw)
Dmitry, from now on I am going to respond only to those of your comments
that to me seem to make some kind of sense and have not been discussed
before. From my omissions you may deduce my opinion of the remainder.
Dmitry A. Kazakov wrote:
>>> 2. It would be extremely ill-advised to use Ada.Execution_Time instead of
>>> direct measures for an implementation of time sharing algorithms.
Niklas Holsti replied:
>> If by "direct measures" you mean the use of some external measuring
>> device such as an oscilloscope or logic analyzer, such measures are
>> available only externally, to the developers, not within the Ada program
>> itself.
Dmitry:
> You forgot one external device called real time clock.
And you seem to forget that Ada.Execution_Time may be implemented by
reading a real-time clock. As has been said before.
Dmitry:
>>> I don't
>>> care how much processor time my control loop takes so long it manages to
>>> write the outputs when the actuators expect them.
Niklas:
>> You should care, if the processor must also have time for some other
>> tasks of lower priority, which are preempted by the control-loop task.
Dmitry:
> Why? It is straightforward: the task of higher priority level owns the
> processor.
Do you mean that your system has only one task with real-time deadlines,
and no CPU time has to be left for lower-priority tasks, and no CPU time
is taken by higher-priority tasks? Then scheduling is trivial for your
system and your system is a poor example for a discussion about scheduling.
Niklas:
>> For example, assume that the computation in a control algorithm consists
>> of two consecutive stages where the first stage processes the inputs
>> into a state model and the second stage computes the control outputs
>> from the state model. Using Ada.Execution_Time or
>> Ada.Execution_Time.Timers the program could detect an unexpectedly high
>> CPU usage in the first stage, and fall back to a simpler, faster
>> algorithm in the second stage, to ensure that some control outputs are
>> computed before the deadline.
Dmitry:
> No, in our systems we use a different schema.
So what? I said nothing (and know nothing) about your system, any
resemblance is coincidental. And there can be several valid schemas.
> The "fall back" values are
> always evaluated first. They must become ready at the end of each cycle. A
> finer estimation is evaluated in background and used when ready.
So your problem is different (the coarse values are the rule). Different
problem, different solution.
> In general, real-time systems are
> usually designed for the worst case scenario,
Yes, but this is often criticized as inefficient, and there are
scheduling methods that make good use of the difference (slack) between
actual and worst-case execution times. These methods need something like
Ada.Execution_Time. As has been said before.
> Consider a system with n-processors. The execution
> time second will be 1/n of the real time second.
No. If you have n workers digging a ditch, you must pay each of them the
same amount of money each hour as if you had one worker. So the "digging
hour" is still one hour, although the total amount of work that can be
done in one hour is n digging-hours. You are confusing the total amount
of work with the amount of work per worker.
With n processors the system can do n seconds worth of execution in one
real-time second. But each processor still executes for one second. And
as I understand the Ada task dispatching/scheduling model, one task
cannot execute at the same time on more than one processor, so one task
cannot accumulate more than one second of execution time in one second
of real time.
(At the risk of introducing another side issue, I note that an
automatically parallelizing compiler might make a task use several
processors in parallel, at least for some of the time. But I don't think
that RM D2.1 considers this possibility.)
> With shared memory it will
> be f*1/n, where f is some unknown factor.
I agree that variable memory access times, and other dynamic timing that
may depend on the number of processors and on how they share resources,
is a complicating factor in the analysis of CPU loads and
schedulability. Indeed this is why I fear that the concept of "the
execution time of task" is becoming fearsomely context-dependent and
therefore problematic -- something that you disagreed with.
For the definition of Ada.Execution_Time, memory access latency is
relevant only if the Ada RTS suspends tasks that are waiting for memory
access, so that they are "not executing" until the memory access is
completed. Most RTOSes do not suspend tasks in that way, I believe.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
^ permalink raw reply [relevance 0%]
* Re: An Example for Ada.Execution_Time
2010-12-28 2:31 6% ` BrianG
@ 2010-12-28 13:43 0% ` anon
2010-12-29 3:10 0% ` Randy Brukardt
1 sibling, 0 replies; 18+ results
From: anon @ 2010-12-28 13:43 UTC (permalink / raw)
In <ifbi5c$rqt$1@news.eternal-september.org>, BrianG <briang000@gmail.com> writes:
>anon@att.net wrote:
>> You ask for an example.
>I'll assume I am the "you". (Since you don't specify and didn't relate
>it to the original thread.)
>
>I asked for:
> >> An algorithm comparison program might look like:
> >>
> >> with Ada.Execution_Time ;
> >> with Ada.Execution_Time.Timers ;
> >Given the below program, please add some of the missing details to
> >show how this can be useful without also "with Ada.Real_Time".
> >Neither Execution_Time or Execution_Time.Timers provides any value
> >that can be used directly.
> >
> >>
> >> procedure Compare_Algorithm is
> >...]
>
>You provided:
>>
>> Here is an example for packages (Tested using MaRTE):
>....
>> with Ada.Execution_Time ;
>> with Ada.Real_Time ;
>....
>> with Ada.Execution_Time ;
>> with Ada.Execution_Time.Timers ;
>> with Ada.Real_Time ;
>....
>
>As the extracts show, you could not do what I asked for. You said in
>the original post you could do it with only the 2 Execution_Time
>'with's. My entire point in this thread is that Execution_Time, as
>defined, is useless by itself.
>
>--BrianG
I changed the title so there was no need for reference lines
Since 2006, a number of people have ask about Ada.Execution_Time package
and no one has given a true example that uses that package for what it was
created for. Until now! I gave you a simple example that can be easily
modified to a more complex program. Problem: may be whats the maximum
number of timers that can be allocated.
and for your info (changes in work.adb)
Task_0 : Work_Task ;
Task_1 : Work_Task ;
Task_2 : Work_Task ;
Task_3 : Work_Task ;
begin
Initialize ( Work_Algorithm'Access ) ;
Task_0.Start ( False ) ;
Task_1.Start ( False ) ;
Task_2.Start ( True ) ; -- just for a change
Task_3.Start ( True ) ;
...
will gives four tasks with four different timers.
2 timers that have the same interval
2 timers that changes the interval
All that is needed is protect the Counter variable for each task and change the
Counter print routine. And I will let others do that modification.
^ permalink raw reply [relevance 0%]
* Re: An Example for Ada.Execution_Time
2010-12-27 18:26 6% An Example for Ada.Execution_Time anon
@ 2010-12-28 2:31 6% ` BrianG
2010-12-28 13:43 0% ` anon
2010-12-29 3:10 0% ` Randy Brukardt
0 siblings, 2 replies; 18+ results
From: BrianG @ 2010-12-28 2:31 UTC (permalink / raw)
anon@att.net wrote:
> You ask for an example.
I'll assume I am the "you". (Since you don't specify and didn't relate
it to the original thread.)
I asked for:
>> An algorithm comparison program might look like:
>>
>> with Ada.Execution_Time ;
>> with Ada.Execution_Time.Timers ;
>Given the below program, please add some of the missing details to
>show how this can be useful without also "with Ada.Real_Time".
>Neither Execution_Time or Execution_Time.Timers provides any value
>that can be used directly.
>
>>
>> procedure Compare_Algorithm is
>...]
You provided:
>
> Here is an example for packages (Tested using MaRTE):
...
> with Ada.Execution_Time ;
> with Ada.Real_Time ;
...
> with Ada.Execution_Time ;
> with Ada.Execution_Time.Timers ;
> with Ada.Real_Time ;
...
As the extracts show, you could not do what I asked for. You said in
the original post you could do it with only the 2 Execution_Time
'with's. My entire point in this thread is that Execution_Time, as
defined, is useless by itself.
--BrianG
^ permalink raw reply [relevance 6%]
* Re: Ada.Execution_Time
2010-12-27 20:11 4% ` Ada.Execution_Time Niklas Holsti
@ 2010-12-27 21:53 0% ` Dmitry A. Kazakov
2010-12-28 14:46 0% ` Ada.Execution_Time Niklas Holsti
0 siblings, 1 reply; 18+ results
From: Dmitry A. Kazakov @ 2010-12-27 21:53 UTC (permalink / raw)
On Mon, 27 Dec 2010 22:11:18 +0200, Niklas Holsti wrote:
> Dmitry A. Kazakov wrote:
>> Technically, CPU_Time is not a number in any sense. It is not a numeric Ada
>> type and it is not a model of a mathematical number (not even additive).
>
> RM D.14(12/2): "The type CPU_Time represents the execution time of a
> task. The set of values of this type corresponds one-to-one with an
> implementation-defined range of mathematical integers". Thus, a number.
This is true for any value of any type due to finiteness. I think
D.14(12/2) refers to an ability to implement Split. But that is irrelevant.
CPU_Time is not declared numeric, it does not have +.
>>>> 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.
>>
>> Let's call it dispatcher. Time sharing needs some measure of consumed CPU
>> time. My points stand:
>>
>> 1. Time sharing has little to do with real-time systems.
>
> What do you mean by "time sharing"? The classical mainframe system used
> interactively by many terminals? What on earth does that have to do with
> our discussion? Such a system of course must have concurrent tasks or
> processes in some form, but so what?
Because this is the only case where execution time might be any relevant to
the algorithm of task switching.
> If by "time sharing algorithms" (below in your point 2) you mean what is
> usually called "task scheduling algorithms", where several tasks
> time-share the same processor by a task-switching (dispatching)
> mechanism, your point 1 is bizarre. Priority-scheduled task switching is
> the canonical architecture for real-time systems.
, which architecture makes execution time irrelevant to switching
decisions.
>> 2. It would be extremely ill-advised to use Ada.Execution_Time instead of
>> direct measures for an implementation of time sharing algorithms.
>
> If by "direct measures" you mean the use of some external measuring
> device such as an oscilloscope or logic analyzer, such measures are
> available only externally, to the developers, not within the Ada program
> itself.
You forgot one external device called real time clock.
> The whole point of Ada.Execution_Time is that it is available to
> the Ada program itself, enabling run-time decisions based on the actual
> execution times of tasks.
, which would be ill-advised to do.
>>>>> 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 disagree with almost everything here. To start with, comparing real-time
>> clock services of Windows and of VxWorks, we would notice that Windows is
>> far superior in both accuracy and precision.
>
> So what? Real-time systems need determinism. The clock only has to be
> accurate enough.
Sorry, are you saying that lesser accuracy of real-time clock is a way to
achieve determinism?
> If your tasks suffer arbitrary millisecond-scale suspensions or
> dispatching delays (as is rumored for Windows) a microsecond-level clock
> accuracy is no help.
And conversely, the catastrophic accuracy of the VxWorks real-time clock
service does not hinder its usability for real-time application. Which is
my point. You don't need good real-time clock in so many real-time
applications, and you never need execution time there.
> Anyway, your point has do to with the "time" that *activates* tasks, not
> with the measurement of task-specific execution times.
Exactly
> So this is irrelevant.
No, it is the execution time which is irrelevant for real-time systems,
because of the way tasks are activated there.
>> I don't
>> care how much processor time my control loop takes so long it manages to
>> write the outputs when the actuators expect them.
>
> You should care, if the processor must also have time for some other
> tasks of lower priority, which are preempted by the control-loop task.
Why? It is straightforward: the task of higher priority level owns the
processor.
>> Measuring the CPU time
>> would bring me nothing. It is useless before the run, because it is not a
>> proof that the deadlines will be met.
>
> In some cases (simple code or extensive tests, deterministic processor)
> CPU-time measurements can be used to prove that deadlines are met.
It is difficult to imagine. This is done either statically or else by
running tests. Execution time has drawbacks of both approaches and
advantages of none.
> For example, assume that the computation in a control algorithm consists
> of two consecutive stages where the first stage processes the inputs
> into a state model and the second stage computes the control outputs
> from the state model. Using Ada.Execution_Time or
> Ada.Execution_Time.Timers the program could detect an unexpectedly high
> CPU usage in the first stage, and fall back to a simpler, faster
> algorithm in the second stage, to ensure that some control outputs are
> computed before the deadline.
No, in our systems we use a different schema. The "fall back" values are
always evaluated first. They must become ready at the end of each cycle. A
finer estimation is evaluated in background and used when ready. Actually,
according to your schema, the finer estimation always "fail" because it is
guaranteed too complex for one cycle. It takes 10-100 cycles to compute at
least. So your schema would not work. In general, real-time systems are
usually designed for the worst case scenario, because when something
unanticipated indeed happens you could have no time to do anything else.
>>> 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.
>>
>> It is explained by its name: "execution time." Execution means not real,
>> unreal time (:-)).
>
> Nonsense. I spend some part of my time asleep, some time awake. Both
> "sleeping time" and "awake time" are (pieces of) real time. A task
> spends some of its time being executed, some of its time not being
> executed (waiting or ready).
A very good example. Now consider your perception of time. Does it
correspond to the real time? No it does not. The time spent in sleep can be
sensed from very short to very long. This felt time is an analogue of the
task execution time. You better do not use this subjective time to decide
when to have next meal. That could end in obesity.
>>>> 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.
>>
>> I see no single reason why this could happen. Obviously, if talking about a
>> real-time system as you insist, the only possible choice for CPU_Time is
>> Time_Span, because to be consistent with the interpretation you propose it
>> must be derived from Ada.Real_Time clock.
>
> I have only said that the sum of the CPU_Times of all tasks executing on
> the same processor should be close to the real elapsed time, since the
> CPU's time is shared between the tasks. This does not mean that
> Ada.Execution_Time.CPU_Time and Ada.Real_Time.Time must have a common
> time source, only that both time sources must approximate physical, real
> time.
What is the reason to use different sources?
>> My point is that RM intentionally leaves it up to the implementation to
>> choose a CPU_Time source independent on Ada.Real_Time.Clock. This why
>> different range and precision come into consideration.
>
> I agree. But in both cases the intent is to approximate physical, real
> time, not some "simulation time" where one "simulation second" could be
> one year of real time.
Certainly the latter. Consider a system with n-processors. The execution
time second will be 1/n of the real time second. With shared memory it will
be f*1/n, where f is some unknown factor. That works in both directions, on
a single processor board with memory connected over some bus system, it
could be f<1, because some external devices might block CPU (and thus your
task) while accessing the memory. Note that the error is systematic. It is
not an approximation of real time.
>> Under some conditions (e.g. no task switching) an execution time interval
>> could be numerically equal to a real time interval.
>
> Yes! Therefore, under these conditions, CPU_Time (when converted to a
> Time_Span or Duration) does have a physical meaning. So we agree. At last.
Since these conditions are never met, the model you have in mind is
inadequate (wrong).
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Re: Ada.Execution_Time
@ 2010-12-27 20:11 4% ` Niklas Holsti
2010-12-27 21:53 0% ` Ada.Execution_Time Dmitry A. Kazakov
0 siblings, 1 reply; 18+ results
From: Niklas Holsti @ 2010-12-27 20:11 UTC (permalink / raw)
Dmitry A. Kazakov wrote:
> On Mon, 27 Dec 2010 14:44:53 +0200, Niklas Holsti wrote:
>
>> 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.
>
> Technically, CPU_Time is not a number in any sense. It is not a numeric Ada
> type and it is not a model of a mathematical number (not even additive).
RM D.14(12/2): "The type CPU_Time represents the execution time of a
task. The set of values of this type corresponds one-to-one with an
implementation-defined range of mathematical integers". Thus, a number.
However, the sub-thread above was not about CPU_Time in
Ada.Execution_Time, but about the general concept "the execution time of
a task". (Serves me right for introducing side issues, although my
intentions were good, I think.)
> Anyway, the execution time can be used in calculations independently on
> whether and how you could apply the results of such calculations.
>
> You can add the height of your house to the distance to the Moon, the
> interpretation is up to you.
You are being absurd.
Dmitri, your arguments are becoming so weird that I am starting to think
that you are just trolling or goading me.
>>> 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.
>
> Let's call it dispatcher. Time sharing needs some measure of consumed CPU
> time. My points stand:
>
> 1. Time sharing has little to do with real-time systems.
What do you mean by "time sharing"? The classical mainframe system used
interactively by many terminals? What on earth does that have to do with
our discussion? Such a system of course must have concurrent tasks or
processes in some form, but so what?
If by "time sharing algorithms" (below in your point 2) you mean what is
usually called "task scheduling algorithms", where several tasks
time-share the same processor by a task-switching (dispatching)
mechanism, your point 1 is bizarre. Priority-scheduled task switching is
the canonical architecture for real-time systems.
> 2. It would be extremely ill-advised to use Ada.Execution_Time instead of
> direct measures for an implementation of time sharing algorithms.
If by "direct measures" you mean the use of some external measuring
device such as an oscilloscope or logic analyzer, such measures are
available only externally, to the developers, not within the Ada program
itself. The whole point of Ada.Execution_Time is that it is available to
the Ada program itself, enabling run-time decisions based on the actual
execution times of tasks.
> Real-time systems work with the real-time, they real-time intervals
> (durations) are of much minor interest. Execution time is of no interest,
> because a real-time system does not care to balance the CPU load.
I am made speechless (or should I say "typing-less"). If that is your
view, there is no point in continuing this discussion because we do not
agree on what a real-time program is.
>>>> 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 disagree with almost everything here. To start with, comparing real-time
> clock services of Windows and of VxWorks, we would notice that Windows is
> far superior in both accuracy and precision.
So what? Real-time systems need determinism. The clock only has to be
accurate enough.
If your tasks suffer arbitrary millisecond-scale suspensions or
dispatching delays (as is rumored for Windows) a microsecond-level clock
accuracy is no help.
> Yet Windows is a half-baked
> time-sharing OS, while VxWorks is one of the leading real-time OSes. Why is
> it so? Because real-time applications do not need clock much. They are
> real-time because their sources of time are *real*. These are hardware
> interrupts, while timer interrupts are of a much lesser interest.
Both are important. Many control systems are driven by timers that
trigger periodic tasks. In my experience (admittedly limited), it is
rare for sensors to generate periodic input streams on their own, they
must usually be sampled by periodic reads. You are right, however, that
some systems, such as automobile engine control units, have external
triggers, such as shaft-rotation interrupts.
Anyway, your point has do to with the "time" that *activates* tasks, not
with the measurement of task-specific execution times. So this is
irrelevant.
> I don't
> care how much processor time my control loop takes so long it manages to
> write the outputs when the actuators expect them.
You should care, if the processor must also have time for some other
tasks of lower priority, which are preempted by the control-loop task.
> Measuring the CPU time
> would bring me nothing. It is useless before the run, because it is not a
> proof that the deadlines will be met.
In some cases (simple code or extensive tests, deterministic processor)
CPU-time measurements can be used to prove that deadlines are met. But
of course static analysis of the worst-case execution time is better.
> It useless at run-time because there
> are easier and safer ways to detect faults.
If you mean "deadline missed" or "task overrun" faults, you are right
that there are other detection methods. Still, Ada.Execution_Time may
help to *anticipate*, and thus mitigate, such faults.
For example, assume that the computation in a control algorithm consists
of two consecutive stages where the first stage processes the inputs
into a state model and the second stage computes the control outputs
from the state model. Using Ada.Execution_Time or
Ada.Execution_Time.Timers the program could detect an unexpectedly high
CPU usage in the first stage, and fall back to a simpler, faster
algorithm in the second stage, to ensure that some control outputs are
computed before the deadline.
But you are again ignoring other run-time uses of execution-time
measurements, such as advanced scheduling algorithms.
>> 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.
>
> It is explained by its name: "execution time." Execution means not real,
> unreal time (:-)).
Nonsense. I spend some part of my time asleep, some time awake. Both
"sleeping time" and "awake time" are (pieces of) real time. A task
spends some of its time being executed, some of its time not being
executed (waiting or ready).
>>> 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.
>
> I see no single reason why this could happen. Obviously, if talking about a
> real-time system as you insist, the only possible choice for CPU_Time is
> Time_Span, because to be consistent with the interpretation you propose it
> must be derived from Ada.Real_Time clock.
I have only said that the sum of the CPU_Times of all tasks executing on
the same processor should be close to the real elapsed time, since the
CPU's time is shared between the tasks. This does not mean that
Ada.Execution_Time.CPU_Time and Ada.Real_Time.Time must have a common
time source, only that both time sources must approximate physical, real
time.
> My point is that RM intentionally leaves it up to the implementation to
> choose a CPU_Time source independent on Ada.Real_Time.Clock. This why
> different range and precision come into consideration.
I agree. But in both cases the intent is to approximate physical, real
time, not some "simulation time" where one "simulation second" could be
one year of real time.
> Under some conditions (e.g. no task switching) an execution time interval
> could be numerically equal to a real time interval.
Yes! Therefore, under these conditions, CPU_Time (when converted to a
Time_Span or Duration) does have a physical meaning. So we agree. At last.
And under the task dispatching model in RM D.2.1, these conditions can
be extended to task switching scenarios with the result that the sum of
the CPU_Times of the tasks (for one processor) will be numerically close
to the elapsed real time interval.
> But in my view the execution time is not even a simulation time of some
> ideal (real) clock. It is a simulation time of some lax recurrent process,
> e.g. scheduling activity, of which frequency is not even considered
> constant.
You may well have this view, but I don't see that your view has anything
to do with Ada.Execution_Time as defined in the Ada RM.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
^ permalink raw reply [relevance 4%]
* An Example for Ada.Execution_Time
@ 2010-12-27 18:26 6% anon
2010-12-28 2:31 6% ` BrianG
0 siblings, 1 reply; 18+ results
From: anon @ 2010-12-27 18:26 UTC (permalink / raw)
You ask for an example.
Here is an example for packages (Tested using MaRTE):
Ada.Execution_Time -- Defines Time type and main operations as
-- well as the primary Clock for this type
Ada.Execution_Time.Timers -- Links to Timers
Altering this example one could use a number of timers to be set
using different times. Or testing a number of algorithms using
the timer.
Also, I do have a Real_Time non-Task version that this example was
based on.
-------------------------------
-- Work.adb -- Main program
with Ada.Integer_Text_IO ;
with Ada.Text_IO ;
with Work_Algorithm ; -- Contains worker algorithm
with Work_Execution_Time ; -- Contains execution Timing routines
procedure Work is
use Ada.Integer_Text_IO ;
use Ada.Text_IO ;
use Work_Execution_Time ;
Task_0 : Work_Task ;
begin -- Work
Initialize ( Work_Algorithm'Access ) ;
Task_0.Start ( False ) ;
-- Prints results of Test
New_Line ;
Put ( "Event occured " ) ;
Put ( Item => Counter, Width => 3 ) ;
Put_Line ( " Times." ) ;
New_Line ;
end Work ;
-------------------------------
-- Work_Algorithm.ads
procedure Work_Algorithm ;
-------------------------------
-- Work_Algorithm.adb
with Ada.Integer_Text_IO ;
with Ada.Text_IO ;
procedure Work_Algorithm is
use Ada.Integer_Text_IO ;
use Ada.Text_IO ;
begin
for Index in 0 .. 15 loop
Put ( "Paused =>" ) ;
Put ( Index ) ;
New_Line ;
delay 1.0 ;
end loop ;
end Work_Algorithm ;
-------------------------------
-- Work.Execution_Time.ads
with Ada.Execution_Time ;
with Ada.Real_Time ;
package Work_Execution_Time is
type Algorithm_Type is access procedure ;
task type Work_Task is
entry Start ( Active : in Boolean ) ;
end Work_Task ;
Counter : Natural ;
procedure Initialize ( A : in Algorithm_Type ) ;
private
Algorithm : Algorithm_Type ;
Start_Time : Ada.Execution_Time.CPU_Time ;
At_Time : Ada.Execution_Time.CPU_Time ;
In_Time : Ada.Real_Time.Time_Span ;
end Work_Execution_Time ;
-------------------------------
-- Work_Execution_Time ;
with Ada.Integer_Text_IO ;
with Ada.Text_IO ;
with Ada.Execution_Time ;
with Ada.Execution_Time.Timers ;
with Ada.Real_Time ;
with Ada.Task_Identification ;
package body Work_Execution_Time is
use Ada.Execution_Time ;
use Ada.Real_Time ;
use Timers ;
package D_IO is new Ada.Text_IO.Fixed_IO ( Duration ) ;
package S_IO is new Ada.Text_IO.Integer_IO
( Ada.Real_Time.Seconds_Count ) ;
protected Handlers is
-- Handler: Single Event
procedure Handler_1 ( TM : in out Timer ) ;
-- Handler: Multple Event
procedure Handler_2 ( TM : in out Timer ) ;
end Handlers ;
task body Work_Task is
use Ada.Task_Identification ;
ID : aliased Task_Id := Current_Task ;
TM : Timers.Timer ( ID'Access ) ;
Cancelled : Boolean := False ;
begin
Counter := 0 ;
loop
select
Accept Start ( Active : in Boolean ) do
if Active then
Start_Time := Ada.Execution_Time.Clock ;
At_Time := Start_Time + Milliseconds ( 5 ) ;
Set_Handler ( TM, AT_Time, Handlers.Handler_2'Access ) ;
else
Start_Time := Ada.Execution_Time.Clock ;
In_Time := Milliseconds ( 10 ) ;
Set_Handler ( TM, In_Time, Handlers.Handler_2'Access ) ;
end if ;
Algorithm.all ; -- Execute Test algorithm
Timers.Cancel_Handler ( TM, Cancelled ) ;
end Start ;
or
terminate ;
end select ;
end loop ;
end Work_Task ;
--
-- Timer Event Routines
--
protected body Handlers is
-- Handler: Single Event
procedure Handler_1 ( TM : in out Timer ) is
Value : Time_Span ;
Cancelled : Boolean ;
begin
Value := Time_Remaining ( TM ) ;
Ada.Text_IO.Put ( "Timing Event Occured at " ) ;
D_IO.Put ( To_Duration ( Value ) ) ;
Ada.Text_IO.New_Line ;
Counter := Counter + 1 ;
Cancel_Handler ( TM, Cancelled ) ;
end Handler_1 ;
-- Handler: Multple Event
procedure Handler_2 ( TM : in out Timer ) is
Value : Time_Span ;
begin
Value := Time_Remaining ( TM ) ;
Ada.Text_IO.Put ( "Timing Event Occured at " ) ;
D_IO.Put ( To_Duration ( Value ) ) ;
Ada.Text_IO.New_Line ;
Counter := Counter + 1 ;
Start_Time := Ada.Execution_Time.Clock ;
In_Time := Ada.Real_Time.Milliseconds ( 10 ) ;
Set_Handler ( TM, In_Time, Handlers.Handler_2'Access ) ;
end Handler_2 ;
end Handlers ;
-- Initialize: Set Algorithm and Counter
procedure Initialize ( A : in Algorithm_Type ) is
begin
Algorithm := A ;
Counter := 0 ;
end Initialize ;
end Work_Execution_Time ;
^ permalink raw reply [relevance 6%]
* Re: Ada.Execution_Time
2010-12-22 14:30 7% ` Ada.Execution_Time anon
@ 2010-12-22 20:09 0% ` BrianG
0 siblings, 0 replies; 18+ results
From: BrianG @ 2010-12-22 20:09 UTC (permalink / raw)
anon@att.net wrote:
> In <iemhm8$4up$1@news.eternal-september.org>, BrianG <briang000@gmail.com> writes:
>> anon@att.net wrote:
>> I have no problem with what Execution_Time does (as evidenced by the
>> fact that I asked a question about its use) - it measures exactly what I
>> want, an estimate of the CPU time used by a task. My problem is with
>> the way it is defined - it provides, by itself, no "value" of that that
>> a using program can make use of to print or calculate (i.e. you also
>> need Real_Time for that, which is silly - and I disagree that that is
>> necessarily required in any case - my program didn't need it otherwise).
>> --BrianG
> There has been many third party versions of this package over the years
> and most of them included a Linux version. The Windows is specific to GNAT.
> And it just like GNAT the Windows version is not complete either.
My comments have been about the RM-defined package and its lack of
usability (if that wasn't already clear). What may or may not be
provided by implementation-specific packages is irrelevant.
>
> For Execution_Time there are three package. GNAT has
> Ada.Execution_Time for both Linux-MaRTE and Windows
> Ada.Execution_Time.Timers only for Linux-MaRTE
> Ada.Execution_Time.Group_Budgets Unimplemented Yet
>
When you say "GNAT" here you should probably specify what version you
mean. I haven't looked in this area, but I was under the impression
that GNAT has implemented all of Ada'05 for quite a while now (in Pro;
maybe it has not yet all reached GCC or GPL releases?).
>
>
> In using the Linux-MaRTE version ( 2 packages )
> Ada.Execution_Time
> Ada.Execution_Time.Timers
See below.
>
> Of course in this example you could use ( Note: they are fully implemented )
> Ada.Real_Time
> Ada.Real_Time.Timing_Events
So, instead of using a functionality already provided (with a slight
kludgy issue), I should implement it entirely myself? I still don't see
how this could get me CPU_Time (even a "simulation" value).
>
>
> An algorithm comparison program might look like:
>
> with Ada.Execution_Time ;
> with Ada.Execution_Time.Timers ;
Given the below program, please add some of the missing details to show
how this can be useful without also "with Ada.Real_Time". Neither
Execution_Time or Execution_Time.Timers provides any value that can be
used directly.
>
> procedure Compare_Algorithm is
>
> task type Algorithm_1 is
> use Ada.Execution_Time.Timers ;
> begin
> begin
> Set_Handler ( ... ) ; -- start timer
> Algorithm_1 ;
> Time_Remaining ( ... ) ; -- sample timer
> end ;
> Cancel_Handler ( ... ) ; release timer
> end ;
>
> task type Algorithm_2 is
> use Ada.Execution_Time.Timers ;
> begin
> begin
> Set_Handler ( ... ) ; -- start timer
> Algorithm_2 ;
> Time_Remaining ( ... ) ; -- sample timer
> end ;
> Cancel_Handler ( ... ) ; release timer
> end ;
>
> use Ada.Execution_Time ;
>
> begin
> -- Start tasks
> -- wait until all tasks finish
> -- compare times using Execution_Time
Provide details here (line above and line below)- without relying on
CPU_Time or Time_Span, which are both private.
> -- Print summary of comparison
> end ;
>
>
--BrianG
^ permalink raw reply [relevance 0%]
* Re: Ada.Execution_Time
@ 2010-12-22 14:30 7% ` anon
2010-12-22 20:09 0% ` Ada.Execution_Time BrianG
0 siblings, 1 reply; 18+ results
From: anon @ 2010-12-22 14:30 UTC (permalink / raw)
In <iemhm8$4up$1@news.eternal-september.org>, BrianG <briang000@gmail.com> writes:
>anon@att.net wrote:
>> In <iejsu9$lct$1@news.eternal-september.org>, BrianG <briang000@gmail.com> writes:
>>> anon@att.net wrote:
>>>> In <ie91co$cko$1@news.eternal-september.org>, BrianG <briang000@gmail.com> writes:
>>>>> Georg Bauhaus wrote:
>>>>>> On 12/12/10 10:59 PM, BrianG wrote:
>>> ....
>>
>> Kind of funny you cutting down "TOP" which can be found on most Linux
>> boxes Which allow anyone with the CPU options turn on to see both the
>> Real_Time and CPU_Time.
>Please provide any comment I made for/against "top". Since my original
>question was based on Windows and I've stated that my (current) Linux
>doesn't support this package, that seems unlikely (even if I didn't
>trust my memory).
>>
>....
>> Note: Not sure of the name for the Windows version of Linux's top.
>There is (that I know of) no real equiv to "top" - as in a command-line
>program. The equiv to GNOME's "System Monitor" (for example - a gui
>program) would be Task Manager (and I made no comment about that either).
>>
>....
>>
>> How to you think these or any other web hosting company could measure the
>> complete system resources without measuring the CPU Execution Time on a
>> given user or application! In Ada, the routines can now use the package
>> called "Ada.CPU_Execution_Time".
>>
>I have no problem with what Execution_Time does (as evidenced by the
>fact that I asked a question about its use) - it measures exactly what I
>want, an estimate of the CPU time used by a task. My problem is with
>the way it is defined - it provides, by itself, no "value" of that that
>a using program can make use of to print or calculate (i.e. you also
>need Real_Time for that, which is silly - and I disagree that that is
>necessarily required in any case - my program didn't need it otherwise).
>>
>--BrianG
There has been many third party versions of this package over the years
and most of them included a Linux version. The Windows is specific to GNAT.
And it just like GNAT the Windows version is not complete either.
For Execution_Time there are three package. GNAT has
Ada.Execution_Time for both Linux-MaRTE and Windows
Ada.Execution_Time.Timers only for Linux-MaRTE
Ada.Execution_Time.Group_Budgets Unimplemented Yet
In using the Linux-MaRTE version ( 2 packages )
Ada.Execution_Time
Ada.Execution_Time.Timers
Of course in this example you could use ( Note: they are fully implemented )
Ada.Real_Time
Ada.Real_Time.Timing_Events
An algorithm comparison program might look like:
with Ada.Execution_Time ;
with Ada.Execution_Time.Timers ;
procedure Compare_Algorithm is
task type Algorithm_1 is
use Ada.Execution_Time.Timers ;
begin
begin
Set_Handler ( ... ) ; -- start timer
Algorithm_1 ;
Time_Remaining ( ... ) ; -- sample timer
end ;
Cancel_Handler ( ... ) ; release timer
end ;
task type Algorithm_2 is
use Ada.Execution_Time.Timers ;
begin
begin
Set_Handler ( ... ) ; -- start timer
Algorithm_2 ;
Time_Remaining ( ... ) ; -- sample timer
end ;
Cancel_Handler ( ... ) ; release timer
end ;
use Ada.Execution_Time ;
begin
-- Start tasks
-- wait until all tasks finish
-- compare times using Execution_Time
-- Print summary of comparison
end ;
^ permalink raw reply [relevance 7%]
* Re: What about a glob standard method in Ada.Command_Line ?
2010-08-22 19:30 4% ` Yannick Duchêne (Hibou57)
@ 2010-08-22 19:46 0% ` Dmitry A. Kazakov
0 siblings, 0 replies; 18+ results
From: Dmitry A. Kazakov @ 2010-08-22 19:46 UTC (permalink / raw)
On Sun, 22 Aug 2010 21:30:35 +0200, Yannick Duch�ne (Hibou57) wrote:
> Le Sat, 21 Aug 2010 11:11:39 +0200, Pascal Obry <pascal@obry.net> a �crit:
>> I see the argument but there is already some APIs that cannot be
>> implemented in some OS (like Ada.Execution_Time.Timers on Win32 for
>> example).
> Will have to check about what Ada.Execution_Time.Timers is exactly,
> because I know there is a timer provided in the Windows API, and for long.
Under Windows there is no way to reliable determine the time a thread owned
CPU. Using existing APIs you can count quants, not the time. The problem is
that when the thread releases processor before it consumed the whole quant,
e.g. by entering non-busy waiting, the pending quant is not counted.
Theoretically you could have 99% CPU usage with 0% indicated in the task
manager.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Re: What about a glob standard method in Ada.Command_Line ?
2010-08-21 9:11 4% ` Pascal Obry
2010-08-22 19:00 0% ` J-P. Rosen
@ 2010-08-22 19:30 4% ` Yannick Duchêne (Hibou57)
2010-08-22 19:46 0% ` Dmitry A. Kazakov
1 sibling, 1 reply; 18+ results
From: Yannick Duchêne (Hibou57) @ 2010-08-22 19:30 UTC (permalink / raw)
Le Sat, 21 Aug 2010 11:11:39 +0200, Pascal Obry <pascal@obry.net> a écrit:
> I see the argument but there is already some APIs that cannot be
> implemented in some OS (like Ada.Execution_Time.Timers on Win32 for
> example).
Will have to check about what Ada.Execution_Time.Timers is exactly,
because I know there is a timer provided in the Windows API, and for long.
^ permalink raw reply [relevance 4%]
* Re: What about a glob standard method in Ada.Command_Line ?
2010-08-21 9:11 4% ` Pascal Obry
@ 2010-08-22 19:00 0% ` J-P. Rosen
2010-08-22 19:30 4% ` Yannick Duchêne (Hibou57)
1 sibling, 0 replies; 18+ results
From: J-P. Rosen @ 2010-08-22 19:00 UTC (permalink / raw)
Le 21/08/2010 11:11, Pascal Obry a ï¿œcrit :
>
> Jean-Pierre,
>
>> 2) Make a good proposal, and make sure it is compiler independent,
>> system independent, powerful and easy to use. Then propose it to the
>> ARG, and the ARG will tell you why it doesn't work ;-)
>
> I see the argument but there is already some APIs that cannot be
> implemented in some OS (like Ada.Execution_Time.Timers on Win32 for
> example). That's not a reason to dismiss it. A glob support for
> Command_Line (in a child package) would be most welcomed even if not
> supported (or supported but with some slight differences) on some OS I
> would say.
>
Sure. And the whole history of Ada is full of stuff where we first said
it was not possible to define in a system independent manner, and later
we changed our mind on the name of usability. Command_Line was dismissed
for Ada 83 and provided in Ada 95. Directory_Operations was dismissed in
Ada 95 and introduced in Ada 2005.
However, it IS too late for Ada 2012, and I'm serious when I say please
propose it; a good proposal is never lost, but it may be harder than you
think.
--
---------------------------------------------------------
J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
^ permalink raw reply [relevance 0%]
* Re: What about a glob standard method in Ada.Command_Line ?
@ 2010-08-21 9:11 4% ` Pascal Obry
2010-08-22 19:00 0% ` J-P. Rosen
2010-08-22 19:30 4% ` Yannick Duchêne (Hibou57)
0 siblings, 2 replies; 18+ results
From: Pascal Obry @ 2010-08-21 9:11 UTC (permalink / raw)
Jean-Pierre,
> 2) Make a good proposal, and make sure it is compiler independent,
> system independent, powerful and easy to use. Then propose it to the
> ARG, and the ARG will tell you why it doesn't work ;-)
I see the argument but there is already some APIs that cannot be
implemented in some OS (like Ada.Execution_Time.Timers on Win32 for
example). That's not a reason to dismiss it. A glob support for
Command_Line (in a child package) would be most welcomed even if not
supported (or supported but with some slight differences) on some OS I
would say.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply [relevance 4%]
Results 1-18 of 18 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2010-08-21 4:47 What about a glob standard method in Ada.Command_Line ? Yannick Duchêne (Hibou57)
2010-08-21 6:41 ` J-P. Rosen
2010-08-21 9:11 4% ` Pascal Obry
2010-08-22 19:00 0% ` J-P. Rosen
2010-08-22 19:30 4% ` Yannick Duchêne (Hibou57)
2010-08-22 19:46 0% ` Dmitry A. Kazakov
2010-12-12 4:19 Ada.Execution_Time BrianG
2010-12-12 16:56 ` Ada.Execution_Time Jeffrey Carter
2010-12-12 21:59 ` Ada.Execution_Time BrianG
2010-12-13 9:28 ` Ada.Execution_Time Georg Bauhaus
2010-12-15 0:16 ` Ada.Execution_Time BrianG
2010-12-15 22:05 ` Ada.Execution_Time Randy Brukardt
2010-12-16 8:45 ` Ada.Execution_Time Dmitry A. Kazakov
2010-12-16 16:49 ` Ada.Execution_Time BrianG
2010-12-16 17:52 ` Ada.Execution_Time Dmitry A. Kazakov
2010-12-17 8:49 ` Ada.Execution_Time Niklas Holsti
2010-12-17 9:32 ` Ada.Execution_Time Dmitry A. Kazakov
2010-12-17 11:50 ` Ada.Execution_Time Niklas Holsti
2010-12-17 13:10 ` Ada.Execution_Time Dmitry A. Kazakov
2010-12-18 21:20 ` Ada.Execution_Time Niklas Holsti
2010-12-19 9:57 ` Ada.Execution_Time Dmitry A. Kazakov
2010-12-25 11:31 ` Ada.Execution_Time Niklas Holsti
2010-12-26 10:25 ` Ada.Execution_Time Dmitry A. Kazakov
2010-12-27 12:44 ` Ada.Execution_Time Niklas Holsti
2010-12-27 15:28 ` Ada.Execution_Time Dmitry A. Kazakov
2010-12-27 20:11 4% ` Ada.Execution_Time Niklas Holsti
2010-12-27 21:53 0% ` Ada.Execution_Time Dmitry A. Kazakov
2010-12-28 14:46 0% ` Ada.Execution_Time Niklas Holsti
2010-12-28 15:42 0% ` Ada.Execution_Time Dmitry A. Kazakov
2010-12-27 22:11 ` Ada.Execution_Time Randy Brukardt
2010-12-29 12:48 ` Ada.Execution_Time Niklas Holsti
2010-12-30 5:06 ` Ada.Execution_Time Randy Brukardt
2010-12-30 23:49 ` Ada.Execution_Time Niklas Holsti
2010-12-31 23:34 ` Ada.Execution_Time Randy Brukardt
2011-01-01 15:54 3% ` Ada.Execution_Time Simon Wright
2010-12-17 8:59 ` Ada.Execution_Time anon
2010-12-19 3:07 ` Ada.Execution_Time BrianG
2010-12-19 22:54 ` Ada.Execution_Time anon
2010-12-20 3:14 ` Ada.Execution_Time BrianG
2010-12-22 14:30 7% ` Ada.Execution_Time anon
2010-12-22 20:09 0% ` Ada.Execution_Time BrianG
2010-12-27 18:26 6% An Example for Ada.Execution_Time anon
2010-12-28 2:31 6% ` BrianG
2010-12-28 13:43 0% ` anon
2010-12-29 3:10 0% ` Randy Brukardt
2014-12-15 16:52 Access parameters and accessibility Michael B.
2014-12-16 7:45 ` Randy Brukardt
2014-12-16 19:46 ` Michael B.
2014-12-17 2:02 3% ` Adam Beneschan
2014-12-17 23:18 0% ` Randy Brukardt
2019-05-30 13:57 Ada 95 Timers: Any Alternatives Available, Storage, Efficiency, Reliability, Accuracy, Et Cetera Issues? Felix_The_Cat@gmail.com
2019-05-30 15:34 ` Niklas Holsti
2019-05-30 16:20 6% ` Dmitry A. Kazakov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox