[Ravenscar] run tasks on events

[Ravenscar] run tasks on events

[Sebastian Hanigk]

Hello,

sorry if this is a stupid question, but as newcomer to Ada I've stumbled
over the following problem: having read a bit on HAL/S which has task
scheduling depending on signals and conditions, I'm a bit at loss how to
implement such functionality in Ada under the Ravenscar profile (no
dynamic task spawning).

The example from the HAL/S user guide were tasks running e.g. only in
the free-fall or ascent/descent phase, started and terminated by
signals.


Thanks for any help or pointers!

Sebastian

Re: run tasks on events

[jimmaureenrogers]

On May 28, 1:14 pm, Sebastian Hanigk <han...@in.tum.de> wrote:
> Hello,
>
> sorry if this is a stupid question, but as newcomer to Ada I've stumbled
> over the following problem: having read a bit on HAL/S which has task
> scheduling depending on signals and conditions, I'm a bit at loss how to
> implement such functionality in Ada under the Ravenscar profile (no
> dynamic task spawning).
>
> The example from the HAL/S user guide were tasks running e.g. only in
> the free-fall or ascent/descent phase, started and terminated by
> signals.
>
> Thanks for any help or pointers!
>
> Sebastian

You can create a task which suspends until the ascent/descent phase.
Simply have the task suspend on an accept statement.
The task will complete its execution upon execution of a rendezvous
associated
with the accept statement. Alternately, the task can start out
executing and
be suspended upon a call to a blocked protected entry.

None of this requires dynamic task allocation.

Jim Rogers

Re: run tasks on events

[ahab]

Have the task immediately call a suspension object or a protected
entry.

You might want to read the Ravenscar Profile Users' Guide here:
http://polaris.dit.upm.es/~ork/documents/

Re: run tasks on events

[Sebastian Hanigk]

ahab <ahabeger@gmail.com> writes:

> Have the task immediately call a suspension object or a protected
> entry.

Hmm, this works only for one task if I'm not mistaken (a suspension
object allows only one blocking call to Suspend_Until_True at the same
time, a protected entry seems to have similar constraints). A solution
would be a suspension object per task, but this is far from the elegance
of HAL/S' signals.


Sebastian

Re: run tasks on events

[Sebastian Hanigk]

"jimmaureenrogers@worldnet.att.net" <jimmaureenrogers@worldnet.att.net>
writes:

> You can create a task which suspends until the ascent/descent phase.
> Simply have the task suspend on an accept statement. The task will
> complete its execution upon execution of a rendezvous associated with
> the accept statement. Alternately, the task can start out executing
> and be suspended upon a call to a blocked protected entry.

Thanks for the pointers! Albeit - as stated in my sibling response - it
lacks the elegance of HAL/S' signal-dependent scheduling.


Sebastian

Re: run tasks on events

[Anh Vo]

On May 29, 3:31 am, Sebastian Hanigk <han...@in.tum.de> wrote:
> ahab <ahabe...@gmail.com> writes:
> > Have the task immediately call a suspension object or a protected
> > entry.
>
> Hmm, this works only for one task if I'm not mistaken (a suspension
> object allows only one blocking call to Suspend_Until_True at the same
> time, a protected entry seems to have similar constraints). A solution
> would be a suspension object per task, but this is far from the elegance
> of HAL/S' signals.
>
> Sebastian

It is not true. Protected entry, implemented in Transient Signals for
example, can suspend/release multiple tasks.

AV

Re: run tasks on events

[Sebastian Hanigk]

Anh Vo <anhvofrcaus@gmail.com> writes:

> It is not true. Protected entry, implemented in Transient Signals for
> example, can suspend/release multiple tasks.

You're right, sorry, I should have perused the ARM beforehand.

I have now created a protected type with a Boolean member, a procedure
to set the Boolean and a protected entry with the Boolean as guard, the
entry's body is empty. Inside the tasks' loops I'm calling the type's
entry which suspends or activates the task depending on the Boolean
flag.

Is this a good or adequate solution or have I missed something critical?


Best regards,

Sebastian

Re: [Ravenscar] run tasks on events

[Niklas Holsti]

Sebastian Hanigk wrote:
> Hello,
> 
> sorry if this is a stupid question, but as newcomer to Ada I've stumbled
> over the following problem: having read a bit on HAL/S which has task
> scheduling depending on signals and conditions, I'm a bit at loss how to
> implement such functionality in Ada under the Ravenscar profile (no
> dynamic task spawning).

Note that Ravenscar has other restrictions, too, which means that 
some of the answers you got are not valid:

jimmaureenrogers@worldnet.att.net wrote:
 > ...
 > You can create a task which suspends until the ascent/descent
 > phase. Simply have the task suspend on an accept statement.
 > The task will complete its execution upon execution of a
 > rendezvous associated with the accept statement.

The Ravenscar profile forbids task entries and rendezvous, so the 
above is not possible. Ravenscar tasks can be controlled only by 
protected object entries and suspension objects from 
Ada.Synchronous_Task_Control.

 >> ahab <ahabe...@gmail.com> writes:
 >>
 >>> Have the task immediately call a suspension object or a
 >>> protected entry.

Both methods work.

 > On May 29, 3:31 am, Sebastian Hanigk <han...@in.tum.de> wrote:
 >> ...
 >> Hmm, this works only for one task if I'm not mistaken (a
 >> suspension object allows only one blocking call to
 >> Suspend_Until_True at the same time...

That's right, so you would need one suspension object per task, 
whether or not the Ravenscar profile is in effect.

 >> a protected entry seems to have similar constraints).

This is true only under the Ravenscar profile, because of the 
Ravenscar restriction that Max_Entry_Queue_Length is 1. In 
unrestricted Ada, many tasks can be waiting on the same entry.

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.

Note that under the Ravenscar profile, one generally needs one 
protected object per (sporadic) task, anyway, to trigger that task 
when required. This protected object can easily be extended with a 
boolean control variable such that the entry triggers the task only 
in the appropriate modes or phases.

On the other hand, personally I'm a bit skeptical about triggering 
certain tasks only in certain modes. I suspect that most systems 
could as well keep the same set of active tasks, and just make the 
tasks do different things in different modes, using plain old "if 
then else" in the task body.

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

Re: [Ravenscar] run tasks on events

[Sebastian Hanigk]

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?

> Note that under the Ravenscar profile, one generally needs one
> protected object per (sporadic) task, anyway, to trigger that task
> when required. This protected object can easily be extended with a
> boolean control variable such that the entry triggers the task only in
> the appropriate modes or phases.

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.

> On the other hand, personally I'm a bit skeptical about triggering
> certain tasks only in certain modes. I suspect that most systems could
> as well keep the same set of active tasks, and just make the tasks do
> different things in different modes, using plain old "if then else" in
> the task body.

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.


Thank you for your help!

Sebastian

Re: [Ravenscar] run tasks on events

[Niklas Holsti]

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

Re: [Ravenscar] run tasks on events

[Sebastian Hanigk]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

Hello!

> 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'm using GNAT 4.0.2 on Solaris 10 (AMD); it seems that my second test
task has silently died.

> [suspension objects per task]
>
> 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.

I have to confess that I was rather enthralled with the simplicity of
the signal/scheduler method ;-)

The difference most likely is only the shift in responsibility: in HAL/S
the programmer simply specifies when to activate tasks, in Ada I have to
do the bookkeeping myself (but I do gain more flexibility).


Thanks for your advice!

Sebastian

Re: [Ravenscar] run tasks on events

[stefan-lucks]

On Fri, 30 May 2008, Niklas Holsti wrote:

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

You don't need this in Ada 05 any more. You can define some callback 
procedures, to do something in the case of unhandled exceptions (and 
normal and abnormal termination as well, if you want to). 


The following is similar to an example in Barnes' book, except that the 
usage avoids race conditions:

--------------------------------------------------------------------------

Package defined in 
<http://www.adaic.org/standards/05rm/html/RM-C-7-3.html>:

with Ada.Task_Identification; with Ada.Exceptions;

package Ada.Task_Termination is
  ...
  type Cause_Of_Termination is (Normal, Abnormal, Unhandled_Exception);
  type Termination_Handler is access protected procedure
    (Cause : in Cause_Of_Termination;
     T     : in Ada.Task_Identification.Task_Id;
     X     : in Ada.Exceptions.Exception_Occurrence);

  procedure Set_Dependents_Fallback_Handler(Handler: in Termination_Handler);
  ...
end Ada.Task_Termination;

--------------------------------------------------------------------------

Specification of Callback:

protected End_Of is
  
  procedure World(C: Cause_Of_Termination;
                  T: Task_ID;
                  X: Exception_Occurrence);

end End_Of;

--------------------------------------------------------------------------

Implementation of Callback:

  procedure World(C: Cause_Of_Termination;
                  T: Task_ID;
                  X: Exception_Occurrence);

  begin
    case C is
      when Normal => 
        null;
      when Abnormal => 
        Put_Log("abnormal termination of Task" & Image(T));
      when Unhandled_Exception =>
        Put_Log("unhandled exception in Task" & Image(T));
        Put_Log(Exception_Information(X));
    end case;
  end World;

--------------------------------------------------------------------------

Usage of callback (typically in main program / environment task):

begin 
  Set_Dependents_Fallback_Handler(End_Of.World);
  declare -- any task you want
    A_Bunch_Of_Tasks: array (0 .. 1023) of Some_Task_Type;
    Alice, Bob: Some_Other_Task_Type;
  begin
    ...
    -- Whenever any of our tasks terminates normally or abnormally or 
    -- propagates an exception, End_Of.World is called. 
  end;
end;




So long

Stefan

-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: run tasks on events

[jimmaureenrogers]

On May 28, 1:14 pm, Sebastian Hanigk <han...@in.tum.de> wrote:
> Hello,
>
> sorry if this is a stupid question, but as newcomer to Ada I've stumbled
> over the following problem: having read a bit on HAL/S which has task
> scheduling depending on signals and conditions, I'm a bit at loss how to
> implement such functionality in Ada under the Ravenscar profile (no
> dynamic task spawning).
>
> The example from the HAL/S user guide were tasks running e.g. only in
> the free-fall or ascent/descent phase, started and terminated by
> signals.
>
> Thanks for any help or pointers!
>
> Sebastian

I am curious why you are comparing unrestrained HAL/S with a
restrained
Ada profile. You can certainly design many interesting shared resource
design patterns using unrestrained Ada.

You might find
http://home.att.net/~jimmaureenrogers/Shared_Resource_Design_Patterns.html
interesting to consider.

Jim Rogers

Re: [Ravenscar] run tasks on events

[Alex R. Mosteo]

Sebastian Hanigk wrote:

> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> 
> Hello!
> 
>> 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'm using GNAT 4.0.2 on Solaris 10 (AMD); it seems that my second test
> task has silently died.

Look also at Ada.Task_Termination, although I don't know if it mix with
ravenscar.

Re: [Ravenscar] run tasks on events

[Ed Falis]

On Fri, 30 May 2008 11:24:22 -0400, Alex R. Mosteo  
<devnull@mailinator.com> wrote:

> Look also at Ada.Task_Termination, although I don't know if it mix with
> ravenscar.

I may be mistaken, but I beleive the Ravenscar profile prohibits any units  
depending on Ada.Task_Termination.

I would also recommend Burns and Wellings "Concurrent and Real Time  
Programming in Ada".  It is extremely comprehensive.

Re: [Ravenscar] run tasks on events

[Sebastian Hanigk]

"Ed Falis" <falis@verizon.net> writes:

> I would also recommend Burns and Wellings "Concurrent and Real Time
> Programming in Ada".  It is extremely comprehensive.

Which edition should I try to get on loan? Our library has only the 1985
edition (which will supposedly be a bit outdated) ... but there's always
lending from a remote library :-)


Sebastian

Re: [Ravenscar] run tasks on events

[Ed Falis]

On Fri, 30 May 2008 14:02:34 -0400, Sebastian Hanigk <hanigk@in.tum.de>  
wrote:

> Which edition should I try to get on loan? Our library has only the 1985
> edition (which will supposedly be a bit outdated) ... but there's always
> lending from a remote library

I would definitely get the newest edition (2007).  Much improved over the  
previous version because Ada 05 addresses issues that had with Ada 95.

Re: run tasks on events

[Sebastian Hanigk]

"jimmaureenrogers@worldnet.att.net" <jimmaureenrogers@worldnet.att.net>
writes:

> I am curious why you are comparing unrestrained HAL/S with a
> restrained Ada profile. You can certainly design many interesting
> shared resource design patterns using unrestrained Ada.

Mostly out of curiosity at the moment. I've stumbled over some shuttle
documents (<http://klabs.org/DEI/Processor/shuttle/index.htm>), read
"Programming in HAL/S" and found a few interesting concepts which
started the endeavour to find similar ones in Ada.

Why Ravenscar? My job will in the foreseeable future provide me with the
opportunity for involvement in the writing of (near-)real-time control
software and I think it will be beneficial to work with a restricted
language subset (Ravenscar + SPARK eventually) from a validation
perspective.

> You might find
> http://home.att.net/~jimmaureenrogers/Shared_Resource_Design_Patterns.html
> interesting to consider.

Great, I'll start reading after supper!


Sebastian

Re: run tasks on events

[Alex R. Mosteo]

Sebastian Hanigk wrote:

> "jimmaureenrogers@worldnet.att.net" <jimmaureenrogers@worldnet.att.net>
> writes:
> 
>> I am curious why you are comparing unrestrained HAL/S with a
>> restrained Ada profile. You can certainly design many interesting
>> shared resource design patterns using unrestrained Ada.
> 
> Mostly out of curiosity at the moment. I've stumbled over some shuttle
> documents (<http://klabs.org/DEI/Processor/shuttle/index.htm>), read
> "Programming in HAL/S" and found a few interesting concepts which
> started the endeavour to find similar ones in Ada.
> 
> Why Ravenscar? My job will in the foreseeable future provide me with the

At least one reason I've heard sometimes is to simplify the runtime, which may
be useful for validation, writing for simple hardware, etc. However, I expect
you'll get more informative replies.


> opportunity for involvement in the writing of (near-)real-time control
> software and I think it will be beneficial to work with a restricted
> language subset (Ravenscar + SPARK eventually) from a validation
> perspective.
> 
>> You might find
>> http://home.att.net/~jimmaureenrogers/Shared_Resource_Design_Patterns.html
>> interesting to consider.
> 
> Great, I'll start reading after supper!
> 
> 
> Sebastian