Re: Barrier re-evaluation issue with GNAT 4.3.2

[Brad Moore <brad.moore@shaw.ca>]

Dmitry A. Kazakov wrote:
> 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.  

A real implementation of Call_Police would hopefully have more effect 
then just printing a message to a console. Yes, Text_IO.Put_Line is 
potentially blocking and clouds the example, thanks for catching that. 
Conceivably though, it may be possible to use some other console output 
that is non-blocking if Call_Police really does need to log something to 
a console. Also, Call_Police does not necessarily need to involve a 
task. For example, it may simply raise a signal on some hardware device 
that calls 911, or turns on a siren, or flashing lights or whatever.
Even if it does perform some protected operation that kicks off another 
task, the timing event approach might hold appeal to some, or be more of 
an appropriate design choice, though in that case, I would probably 
recommend at least considering some other approach such as the use a 
timed/conditional entry call.

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.

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

Whether timing_events is something that will be used a lot in practice 
is another question. I worked on a legacy system (written in Ada 83)
that had a package very similar to timing_events. It was used to
trigger timeouts in a run-to-completion tasking model.
In that environment, the creation of tasks was discouraged, and only
allowed if absolutely necessary. This timing_events package provided a 
convenient way to coordinate the existing tasks and trigger things to 
happen in the future without having to introduce more tasks in the 
system. Of course, as with the standard timing_package, timing events
need to be non-blocking and fast. Had the standard timing package
existed at that time, we probably would have used that instead.

If I were building the system again from scratch, though, maybe I 
wouldn't use timing_events at all.

I suspect that some people will find timing_events to be useful for 
specific types of applications, but probably will not be used on any 
grand scale. I think mostly people should/will want to use other 
existing synchronization mechanisms in Ada to coordinate tasks.

Brad