task model

task model

[Mike]

I'm prototyping some tasking with multiple accepts, the code is as
follows:

with Ada.Text_Io;
use Ada.Text_Io;

procedure task_test is


   procedure Process_Primary(node: in Integer) is

   begin

       Put_Line("This is number" & Integer'Image(node));

   end Process_Primary;


   task proc1 is
     entry process1(node : Integer);
     entry continue;
   end proc1;

   task body proc1 is
   begin

     accept process1( node : Integer) do

       Process_Primary( node );

     end;

     accept continue do
       Put_Line("Called Continue task1");
     end;

   end proc1;

   task proc2 is
     entry process2(node : Integer);
     entry continue;
   end proc2;

   task body proc2 is
   begin

     accept process2( node : Integer) do

         Process_Primary( node );

     end;

     accept continue do
       Put_Line("Called Continue task2");
     end;

   end proc2;


begin
  for i in 1..2 loop
   proc1.process1(1);
   proc2.process2(2);
   proc1.continue;
   proc2.continue;
  end loop;
end task_test;
---------------------------------------------------------------------------------------------------------------------

I get the out put I expect:

This is number 1
This is number 2
Called Continue task1
Called Continue task2


But I also get the following error which I can't track down:

raised TASKING_ERROR : s-tasren.adb:486

I'm running on a Xeon blade with gnat under linux

Thanks
Mike

Re: task model

[Ludovic Brenta]

Michael Tabak wrote on comp.lang.ada:
> I'm prototyping some tasking with multiple accepts, the code is as
> follows:
>
> with Ada.Text_Io;
> use Ada.Text_Io;
>
> procedure task_test is
>
>    procedure Process_Primary(node: in Integer) is
>
>    begin
>
>        Put_Line("This is number" & Integer'Image(node));
>
>    end Process_Primary;
>
>    task proc1 is
>      entry process1(node : Integer);
>      entry continue;
>    end proc1;
>
>    task body proc1 is
>    begin
>
>      accept process1( node : Integer) do
>
>        Process_Primary( node );
>
>      end;
>
>      accept continue do
>        Put_Line("Called Continue task1");
>      end;
>
>    end proc1;
>
>    task proc2 is
>      entry process2(node : Integer);
>      entry continue;
>    end proc2;
>
>    task body proc2 is
>    begin
>
>      accept process2( node : Integer) do
>
>          Process_Primary( node );
>
>      end;
>
>      accept continue do
>        Put_Line("Called Continue task2");
>      end;
>
>    end proc2;
>
> begin
>   for i in 1..2 loop
>    proc1.process1(1);
>    proc2.process2(2);
>    proc1.continue;
>    proc2.continue;
>   end loop;
> end task_test;
> ---------------------------------------------------------------------------------------------------------------------
>
> I get the out put I expect:
>
> This is number 1
> This is number 2
> Called Continue task1
> Called Continue task2
>
> But I also get the following error which I can't track down:
>
> raised TASKING_ERROR : s-tasren.adb:486

Your expectations are wrong :)

Your environment task contains a loop calling each task four times:
for each task the call sequence is processN, continue, processN,
continue.  But the tasks do not contain a loop, so they can accept
only the first two entry calls and then they terminate.  So the second
call to process1 raises Tasking_Error because task1 has terminated by
now.

HTH

--
Ludovic Brenta.

Re: task model

[Anh Vo]

On Oct 15, 11:00 am, Ludovic Brenta <ludo...@ludovic-brenta.org>
wrote:
> Michael Tabak wrote on comp.lang.ada:
>
> > I'm prototyping some tasking with multiple accepts, the code is as
> > follows:
>
> > with Ada.Text_Io;
> > use Ada.Text_Io;
>
> > procedure task_test is
>
> >    procedure Process_Primary(node: in Integer) is
>
> >    begin
>
> >        Put_Line("This is number" & Integer'Image(node));
>
> >    end Process_Primary;
>
> >    task proc1 is
> >      entry process1(node : Integer);
> >      entry continue;
> >    end proc1;
>
> >    task body proc1 is
> >    begin
>
> >      accept process1( node : Integer) do
>
> >        Process_Primary( node );
>
> >      end;
>
> >      accept continue do
> >        Put_Line("Called Continue task1");
> >      end;
>
> >    end proc1;
>
> >    task proc2 is
> >      entry process2(node : Integer);
> >      entry continue;
> >    end proc2;
>
> >    task body proc2 is
> >    begin
>
> >      accept process2( node : Integer) do
>
> >          Process_Primary( node );
>
> >      end;
>
> >      accept continue do
> >        Put_Line("Called Continue task2");
> >      end;
>
> >    end proc2;
>
> > begin
> >   for i in 1..2 loop
> >    proc1.process1(1);
> >    proc2.process2(2);
> >    proc1.continue;
> >    proc2.continue;
> >   end loop;
> > end task_test;
> > ---------------------------------------------------------------------------­------------------------------------------
>
> > I get the out put I expect:
>
> > This is number 1
> > This is number 2
> > Called Continue task1
> > Called Continue task2
>
> > But I also get the following error which I can't track down:
>
> > raised TASKING_ERROR : s-tasren.adb:486
>
> Your expectations are wrong :)
>
> Your environment task contains a loop calling each task four times:
> for each task the call sequence is processN, continue, processN,
> continue.  But the tasks do not contain a loop, so they can accept
> only the first two entry calls and then they terminate.  So the second
> call to process1 raises Tasking_Error because task1 has terminated by
> now.

I would like to expand Ludovic's comment.

You have a couple of options to improve it.

1. Make sure the task not terminated before calling its entry. That is
using proc1'terminated syntax to query it.
2. Add infinite loop enclosing accept statements. So, entry call can
be served always. This makes tasks alive even after the program ends
(program will hang) unless Ctrl-C or other mean to end it. The clean
solution is add entry Shutdown to the task. When this entry is
invoked, just exit the loop. Thus, the task will terminate cleanly.

Anh Vo

Re: task model

[Dmitry A. Kazakov]

On Thu, 15 Oct 2009 12:15:56 -0700 (PDT), Anh Vo wrote:

> I would like to expand Ludovic's comment.
> 
> You have a couple of options to improve it.
> 
> 1. Make sure the task not terminated before calling its entry. That is
> using proc1'terminated syntax to query it.
> 2. Add infinite loop enclosing accept statements. So, entry call can
> be served always. This makes tasks alive even after the program ends
> (program will hang) unless Ctrl-C or other mean to end it. The clean
> solution is add entry Shutdown to the task. When this entry is
> invoked, just exit the loop. Thus, the task will terminate cleanly.

2'. In order to terminate a task upon parent's completion use select
statement with a terminate alternative:

select
   accept XYZ;
or terminate; -- Ends the task when the parent terminates
end select;

(Shutdown entry is used when terminate is not allowed, e.g. when a delay
alternative or else part is present in the select, or when some explicit
completion code need to be executed, however any local objects are properly
finalized when the terminate alternative is accepted.)

3. Do not do any asynchronous (lengthy) processing within a rendezvous,
i.e. within do...end of an accept. During the rendezvous the caller is
blocked. Rendezvous is meant for short synchronous things, like passing the
parameters and results, then the caller is released and the callee
completes things asynchronously to the caller.

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

Re: task model

[sjw]

On Oct 15, 8:15 pm, Anh Vo <anhvofrc...@gmail.com> wrote:

> 1. Make sure the task not terminated before calling its entry. That is
> using proc1'terminated syntax to query it.

There's a race condition there!

if not proc1'terminated then
   --  <<<<<<<<<<<<<<<<<<<<<preempted by proc1 here, which terminates
   proc1'process1(2);
   --  tasking_error here!
end if;

Re: task model

[Jeffrey R. Carter]

Dmitry A. Kazakov wrote:
> 
> 3. Do not do any asynchronous (lengthy) processing within a rendezvous,
> i.e. within do...end of an accept. During the rendezvous the caller is
> blocked. Rendezvous is meant for short synchronous things, like passing the
> parameters and results, then the caller is released and the callee
> completes things asynchronously to the caller.

You can do anything you choose in an accept statement. Be aware that the calling 
task is blocked until the accept completes.

-- 
Jeff Carter
"Oh Lord, bless this thy hand grenade, that with it thou
mayst blow thine enemies to tiny bits, in thy mercy."
Monty Python and the Holy Grail
24

Re: task model

[Georg Bauhaus]

4.  add an exception handler to your tasks.
Have it print a message, for example, and
then re-raise the exception.  Otherwise tasks
may fail in silence and you never learn what
has happened.

Re: task model

[Brad Moore]

Georg Bauhaus wrote:
> 4.  add an exception handler to your tasks.
> Have it print a message, for example, and
> then re-raise the exception.  Otherwise tasks
> may fail in silence and you never learn what
> has happened.

Or use the Ada 2005 package, Ada.Task_Termination
which allows you to install a handler that
gets called when tasks terminate.

Re: task model

[Jeffrey R. Carter]

Georg Bauhaus wrote:
> 4.  add an exception handler to your tasks.
> Have it print a message, for example, and
> then re-raise the exception.  Otherwise tasks
> may fail in silence and you never learn what
> has happened.

What's the point of re-raising? Exceptions don't propagate from tasks.

-- 
Jeff Carter
"Why, the Mayflower was full of Fireflies, and a few
horseflies, too. The Fireflies were on the upper deck,
and the horseflies were on the Fireflies."
Duck Soup
95

Re: task model

[Georg Bauhaus]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> writes:

> Georg Bauhaus wrote:
>
> What's the point of re-raising? Exceptions don't propagate from tasks.

Uhm, I forgot to mention that a handler at some nesting level
might be reporting, permitting more accurate diagnostic messages.
It could then decide there is or is not a possible rescue,
and accordingly re-raise, for example.

Re: task model

[Dmitry A. Kazakov]

On Sat, 17 Oct 2009 13:10:04 +0200, Georg Bauhaus wrote:

> "Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> writes:
> 
>> Georg Bauhaus wrote:
>>
>> What's the point of re-raising? Exceptions don't propagate from tasks.
> 
> Uhm, I forgot to mention that a handler at some nesting level
> might be reporting, permitting more accurate diagnostic messages.
> It could then decide there is or is not a possible rescue,
> and accordingly re-raise, for example.

The problem is that there is no nesting of tasks in terms of control flow.
There is a parent child relation, but it is no nesting.

If an exception is propagated out of a task, the parent task is doing its
things asynchronously to the child. In order to propagate an exception in
the parent you have only two options:

1. an asynchronous transfer of control = in effect aborting/interrupting
the parent;
2. to synchronize with the parent making a rendezvous with it.

Neither looks much promising.

More generally speaking in Ada tasks are objects. As an object a failed
task may complain no earlier than upon its finalization if no other
contacts (rendezvous) happen. This is too late in all senses.

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

Re: task model

[Jeffrey R. Carter]

Georg Bauhaus wrote:
>>
>> What's the point of re-raising? Exceptions don't propagate from tasks.
> 
> Uhm, I forgot to mention that a handler at some nesting level
> might be reporting, permitting more accurate diagnostic messages.
> It could then decide there is or is not a possible rescue,
> and accordingly re-raise, for example.

Not an exception handler for the task, then, but for a declare statement within 
the task. In that case, a re-raise might be useful.

However, the primary use I have had for such a structure is to enclose an accept 
statement, allowing an explicitly raised exception to propagate from the accept 
to the caller, while being handled and ignored in the called task.

-- 
Jeff Carter
"You've got the brain of a four-year-old boy,
and I bet he was glad to get rid of it."
Horse Feathers
47

Re: task model

[Jean-Pierre Rosen]

Georg Bauhaus a �crit :
> 4.  add an exception handler to your tasks.
> Have it print a message, for example, and
> then re-raise the exception.  Otherwise tasks
> may fail in silence and you never learn what
> has happened.
This pattern can be enforced by the following rule ine AdaControl:

check exception_propagation (task);

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr