Re: Barrier re-evaluation issue with GNAT 4.3.2

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

On Fri, 25 Sep 2009 11:06:05 -0600, Brad Moore wrote:

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

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.

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

Speaking generally, IMO, the design should be driven by the worker tasks
rather than by events, because the system load is inflicted by the workers,
not by event propagation. An event implemented by protected actions are in
effect synchronous or else you have some task that reads out some queue of
events. There is no way to work around this. Either you process the event
right at the spot it was triggered (=you don't have events at all), or else
you postpone event handling to another task later. The bottom line, events
need tasks or else do not exist...

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

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