Re: Barrier re-evaluation issue with GNAT 4.3.2

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

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