Prev: Newbie question: How to use gnat make
Next: Performance of access type : a tiny mistake in the WikiBook ?
From: Brad Moore on 25 Sep 2009 15:39
Dmitry A. Kazakov wrote:
> This would mean that the hardware device encapsulated that task (e.g. HDD
> controller). I don't think this could be considered a realistic scenario.
> Hardware I/O on most platforms is too slow to be performed from a protected
> action. If you have an OS, it is 10-100 times slower, at least. Doing this
> within a protected action is not a good idea. One can imagine protected
> action as a being performed by a task with highest real-time priority.
> Without OS, considering low-level I/O, like DAQ boards, DMA access etc, the
> performance penalty might be even higher.

I was thinking more along the lines of changing the voltage of some
output port on some device, or writing directly to the console buffer,
rather than invoking some dialog with a HDD controller.
Depending on the device, it may be as simple as writing a single value
to some memory address. Technically, this is a non-blocking scenario. It
may (or may not) be slower than normal memory writes, but still
satisfies RM 9.5.1(8). Just because it is protected, does not mean it
cannot be preempted by a higher priority (e.g. interrupt) task. It wont
cause deadlock. I think this is very much a realistic scenario.

>
>> Timing_Events should handle a reasonable number of events in the system.
>> If your application has millions of these firing all over the place,
>> then scalability could become an issue, and perhaps for such a system,
>> some alternate design would be more appropriate.
>
> No, because these events need to be handled by somewhere. Million events
> handled by one task? That is the monitor task taking the shortest delay
> from a queue of. Million tasks will not work anyway.

I was agreeing with you that scalability could become an issue.
Channeling everything through a single timer task (if that is how it is
implemented) could introduce unacceptable latencies, if the number
events grows too large.

>>> Timing_Events does not have any advantages over delay or asynchronous
>>> transfer of control. I guess it was provided for some low-level stuff like
>>> interrupts from hardware timers. However there was already a support for
>>> interrupts mapped into protected operations, so it really puzzles me why
>>> Timing_Events were added.
>> I see timing events as being potentially useful reusable concurrency
>> component.
>> If you ever need something that looks like timing_events, then hopefully
>> it will save you from having to write your own. It may have utility in
>> some areas such as discrete event simulation, for example, if you need
>> something to coordinate multiple tasks and ensure that signalling events
>> occur and run to completion before before signaling subsequent events.
>
> This is IMO a different case, e.g. pulse events. Yes I have an
> implementation of pulse events. But I don't see why pulse events cannot be
> signaled from a scheduler task. The event source is unrelated to the way an
> event is handled. Basically Timing_Events saves you exactly one "scheduler"
> task, keeping in mind that the implementation of could deploy some hidden
> task (thread) anyway. It does not save you the worker task(s).
>

Agreed, timing_events *is* basically a scheduler task. In my example,
assuming Call_Police is not potentially blocking, and you try to rewrite
the example without having some type of a scheduler task, (whether it be
timing_events or your scheduler), then you may end up having to create
some dedicated task to manage the timeout for the alarm. (Extra to the
thread of control encapsulated by the hardware device) The scheduler
model could be considered as being an improvement over this, but as
system requirements can differ dramatically across different systems, YMMV.

Regards,
Brad
From: John B. Matthews on 26 Sep 2009 10:23
In article <nospam-E7CE69.11564625092009(a)news.aioe.org>,
"John B. Matthews" <nospam(a)nospam.invalid> wrote:

[...]
> <http://www.adaic.com/standards/95rat/RAThtml/rat95-p1-2.html#9>
[...]
> procedure Wakeup(Event : in out Timing_Events.Timing_Event) is
> begin
> Alarm := True;
> Signal;
> end Wakeup;

Oops, procedure Wakeup shouldn't set Alarm; as the article explains, it
should only be "true while tasks are being released."

procedure Wakeup(Event : in out Timing_Events.Timing_Event) is
begin
Signal;
end Wakeup;

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
From: Reto Buerki on 28 Sep 2009 06:18
Dmitry A. Kazakov wrote:
>> Switching the compiler is a solution we consider as last resort.
>
> Switching to a never version looks plausible to me.

Our current development environment is based on Debian/Stable. Switching
to GNAT 4.4 requires us to upgrade the environment to Debian
experimental or testing which could introduce some instabilities.
Furthermore, some work is required to do the actual upgrade.

> I was always wondering the rationale behind introducing
> Ada.Real_Time.Timing_Events. The delay statement does the very same thing:

The code I posted was just a small reproducer for the barrier
re-evaluation bug in FSF GNAT 4.3.2. As stated, the problem has nothing
to do with timing events, it also occurs when a "normal" Ada (scheduler)
task is delayed and calls the Wakeup() procedure. Obviously in this
simple example there's no need for timing events or an additional task.
From: Reto Buerki on 28 Sep 2009 06:28
John B. Matthews wrote:
> I get the same result with FSF GNAT 4.3.4. I revised your code to follow
> the "protected Event" example seen here:
>
> <http://www.adaic.com/standards/95rat/RAThtml/rat95-p1-2.html#9>
>
> It seems to work. The compiler warns, "potentially blocking operation in
> protected operation" in Wakeup, although the Signal barrier is always
> true. I'm not sure the extra entries _should_ be required, but I think
> it might be more reliable in the face of multiple threads calling Wait.
> I don't know a reason why it wouldn't work under 4.3.2.

Thanks for your effort in confirming the issue with GNAT 4.3.4 and for
the "protected Event" example.

We will see how we can integrate your idea into our project as a
workaround for the re-evaluation problem.
From: Reto Buerki on 28 Sep 2009 06:41
Jean-Pierre Rosen wrote:
> Dmitry A. Kazakov a �crit :
>> Timing_Events does not have any advantages over delay or asynchronous
>> transfer of control. I guess it was provided for some low-level stuff like
>> interrupts from hardware timers. However there was already a support for
>> interrupts mapped into protected operations, so it really puzzles me why
>> Timing_Events were added.
>>
> The answer is easy: because users asked for it. Of course, it is
> useless, but some people don't feel easy with tasks, and want to use the
> kind of tools they are accustomed to.
>
> So rather than painfully answering requests like "why doesn't Ada have
> that feature", it was simpler to say "what's the heck" and provide it.
> If you don't like it (I am also in that case), don't use it.

Could you elaborate the negative aspects of Ada.Real_Time.Timing_Events?

We found using timing events was straightforward and lightweight.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Prev: Newbie question: How to use gnat make
Next: Performance of access type : a tiny mistake in the WikiBook ?