Re: [Ravenscar] run tasks on events

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

Sebastian Hanigk wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> 
> 
>>Anh Vo wrote:
>>
>>>It is not true. Protected entry, implemented in Transient
>>>Signals for example, can suspend/release multiple tasks.
>>
>>True in unrestricted Ada (an entry queue can hold many tasks), false
>>under the Ravenscar profile (maximum one task waiting on an entry). If
>>you use protected objects to trigger tasks, you need one object per
>>task.
> 
> 
> Argh. Seems I was too early in my reply to Anh Vo ...
> 
> Shouldn't there be a constraint error?

Acccording to LRM D.7.19(1/2), violation of Max_Entry_Queue_Length 
raises Program_Error at the violating entry call.

In unrestricted Ada, if an exception occurs in a task, and the task 
does not handle the exception, the task by default terminates 
silently when the exception propagates out of the task. If you want 
to know about exceptions in a task, you should put a last-chance, 
catch-all exception handler in the task body ("exception when 
others => ...").

Since the Ravenscar profile contains the restriction 
No_Task_Termination, by LRM D.7.15(1/2) it is implementation 
defined what happens when a Ravenscar task terminates due to an 
unhandled exception or for other reasons. It may be reported or 
signalled in some way, or not.

> I hadn't included the Profile pragma in all my source files, so I'm
> assuming that the successful test earlier on was due to not complying
> with the Ravenscar profile. Having put the pragma directives into the
> source code, now only one of the waiting tasks resumes/suspends.

The Profile pragma is a "configuration" pragma. If you use Gnat, 
you should normally put configuration pragmas in a separate file 
called "gnat.adc", and Gnat will then include them in all 
compilations. See the GNAT User Guide; I haven't used such pragmas 
myself, so I'm not expert.

> Well, I found the signaling/scheduling concept very elegant; now it
> seems my best bet would be a check inside each task's loop if the
> respective conditions evaluate to True, otherwise simply delay until the
> next period.

That is a good solution for periodic tasks, where the task is 
triggered by "delay until" and not by an event. Of course you will 
waste some processor time on unnecessary activations of the task. 
To avoid that, make the task suspend itself on a suspension object 
(a different object for each task) when the task has nothing to do. 
The "elegance" of this solution is subjective, of course, but I 
don't find it very ugly to have a different object for each task; 
it even makes it easier to select the subset of tasks that should 
become active.

Note also that transitions between phases or modes must be planned 
and implemented carefully, perhaps over more than one task cycle, 
to avoid transients (both control transients and 
performance/deadline transients) during the transition.

HTH,

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .