Re: Barrier re-evaluation issue with GNAT 4.3.2

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 25 Sep 2009 02:50:32 -0600, Brad Moore wrote:

> Dmitry A. Kazakov wrote:
>> I was always wondering the rationale behind introducing
>> Ada.Real_Time.Timing_Events. The delay statement does the very same thing:
>> 
>> with Ada.Real_Time;  use Ada.Real_Time;
>>    ...
>>    Event : Time;
>> begin
>>    ...
>>    Put_Line ("Starting alarm ...");
>>    Event := Clock + To_Time_Span (3.0);
>> 
>>    Put_Line ("Waiting for alarm ...");
>>    delay until Event;
>>    Put_Line ("ALARM!!");
> 
> In this trivial example, a simple delay is probably all you need.
> 
> However, consider a slightly different twist on the alarm example.
> Suppose you have a burglar alarm where if you trip the alarm
> you have 1 minute to correctly enter the security code, or
> the police are called. If you correctly enter the code in time
> the alarm is canceled. This gets you into the realm where
> the timing events package is more useful.
> 
> You could accomplish this also using a task to monitor the timeout, but 
> that could be considered a "heavier" approach depending on the 
> implementation of the timing events package. Timing events provide a 
> simpler abstraction, if all you want is an event to fire at sometime in 
> the future. Plus if you have many such sort of events in a program, you 
> could potentially save yourself from having to add tasks for each event 
> you want to monitor, resulting in less system resources being used.

You must do it per a monitor task anyway. Your design is not scalable, and
the code is not conformant to Ada, because you are using potentially
blocking Put_Line within a protected action (in Call_Police).

When an alarm is triggered, that happens at the context of a protected
action. The protected action is quite limited to what you could do there.
That is only non-blocking and *very* short stuff. This means that you won't
be able to "call police" from there. You could set some flags, but you
could not initiate any "non-instant" action otherwise than by releasing a
task. Non-instant actions are for tasks. You need a task. If the key input
task gets blocked beyond reach of asynchronous transfer of control, which
is your case, because Ada does not require Text_IO abortable (yet
misleadingly provides an example of in RM (:-)), anyway, that means, you
inescapably need a second task.  

-----------
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.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de