Problem with tasks

Problem with tasks

[Carlos Aganzo]

I need to create a new instance of the same task from itself,
something like

 type acell is access cell;

 task body cell is
    anon: acell;
    begin
       anon := new cell;
       -- more code
 end cell;


 How could I do this?

 Is there any way to create anonymous tasks instances,  Java-like?

 Thanks in advance.

 Carlos.

Re: Problem with tasks

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 899 bytes --]


"Carlos Aganzo" <carlos_aganzo@terra.es> a �crit dans le message news: 3b5e887e.10671695@news.bt.es...
> I need to create a new instance of the same task from itself,
> something like
>
>  type acell is access cell;
>
>  task body cell is
>     anon: acell;
>     begin
>        anon := new cell;
>        -- more code
>  end cell;
>
>
>  How could I do this?
A task type name designates the current instance within its own body, so that you can write:
   abort cell;
to abort the current task. If you want to use it as the type name, just declare a subtype:
  subtype Cell_Again is Cell;  -- declaration must be outside body!
  task body cell is
     anon: acell;
     begin
        anon := new cell_Again;
        -- more code
  end cell;


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

Re: Problem with tasks

[DuckE]

If you move the code that creates the task outside of the task body (into a
function or procedure) things appear to work fine.

  task type cell;

  type cell is access cell;

  procedure create_cell is
    anon : acell;
  begin
     anon := new cell;
  end create_cell;

  task body cell is
  begin
    create_cell;
  end cell;

SteveD

"Carlos Aganzo" <carlos_aganzo@terra.es> wrote in message
news:3b5e887e.10671695@news.bt.es...
> I need to create a new instance of the same task from itself,
> something like
>
>  type acell is access cell;
>
>  task body cell is
>     anon: acell;
>     begin
>        anon := new cell;
>        -- more code
>  end cell;
>
>
>  How could I do this?
>
>  Is there any way to create anonymous tasks instances,  Java-like?
>
>  Thanks in advance.
>
>  Carlos.
>

Re: Problem with tasks

[Carlos Aganzo]

Thanks to everybody for their help :)

Carlos.

Re: Problem with tasks

[Ted Dennison]

In article <3b5e887e.10671695@news.bt.es>, Carlos Aganzo says...
>
>I need to create a new instance of the same task from itself,

First off, this sounds like you designed a system around the "fork" concept, and
are now trying to plug that into Ada. You'll have a lot easier time if you
*design* from Ada too. But as a beginner, it may be a while before you know
enough Ada to do that. In the meantime, it might be worthwhile to take a step
back and tell us what you are trying to accomplish with your "fork".

If you want to dynamicly create tasks in Ada, you should be using task types.
You can create pointers to task type objects, put them in arrays, dynamicly
allocate and deallocate them, etc. You can even create them from within
themselves, if you *truly* need something like "fork". That type of activity can
lead to "fork-bomb" errors though. 


---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Problem with tasks

[Ehud Lamm]

Ted Dennison <dennison@telepath.com> wrote in message
news:HbX77.7784$ar1.25497@www.newsranger.com...
> In article <3b5e887e.10671695@news.bt.es>, Carlos Aganzo says...
> >
> >I need to create a new instance of the same task from itself,
>
> First off, this sounds like you designed a system around the "fork"
concept, and
> are now trying to plug that into Ada. You'll have a lot easier time if you
> *design* from Ada too.

Maybe. But sometimes the design call for this type of behaviour, and it has
nothing to do with forking.

> If you want to dynamicly create tasks in Ada, you should be using task
types.
> You can create pointers to task type objects, put them in arrays,
dynamicly
> allocate and deallocate them, etc. You can even create them from within
> themselves, if you *truly* need something like "fork". That type of
activity can
> lead to "fork-bomb" errors though.
>

Right. That's why a good design would make use of a task-allocator
abstraction, which may allocate a new taks, but may later be changed to
manage a finite sized pool of tasks (the "thread pool" pattern).


Ehud Lamm

Re: Problem with tasks

[Ehud Lamm]

> Right. That's why a good design would make use of a task-allocator
> abstraction, which may allocate a new taks, but may later be changed to
> manage a finite sized pool of tasks (the "thread pool" pattern).
>


Creating such a task allocator (or manager) abstraction is far from trivial.
Some difficulties stem from Ada's apporach to tasking.

Ada tasks types are not polymorphic, in the sense of allowing you create
code that accepts any tasks supporting a given interface.
In Ada95 we can solve this problem by vreating a tagged type that
encapsualtes the task: All task type that support a given interface will
simply derive from this type, allowing us to code class-wide routines, store
them in heterogenous structures etc.
(This approach has some problem. Using this approach we will not call task
entries directly, but rather by using a wrapper routine. The excludes the
possibility of timed-entry calls etc. This approach is also rather
cumbersome and verbose).

Another related issue is that tasks in this scheme must all behave along
similar lines (e.g., they usually all have to be server tasks accepting work
inside a loop.  Exit/Restart entries may be needed, esp. if you want to
support resing existing tasks instead of allocating new tasks, and task may
have initial operation and state).
In a sense we may want parametrized tasks.
There are several ways of doing this in Ada: using generic packages (but
this is a bit restrctive), or using another tagged type hierarchy, and have
tasks parametrized (using an access discr. for example) with a specific type
defining their behaviour.

Other more technical design issues exist. A major issue is copying tasks
(tasks are limited, so one must use access values), and GC them
(Controlledness maybe problematic with all the inheritance going around, we
don't have MI). We must also remember that tasks are by their very nature
mutable: a task has state. This makes aliasing very problematic, and thus
copying tasks is essential, yet difficult (recall that the tasks themselves
are "limited"). How do we solve this prolem?
If you answer is to use task allocator abstracion, You should reread this
message... :-)

All this makes this an interesting problem. I'd love to hear experiences
people had with building such a thing (esp. in Ada95, since it offers what
seem to me to be useful tools).
My attempts are in rather more restricted domain; when finished I'll put
them up somewhere.


Ehud Lamm

Re: Problem with tasks

[Carlos Aganzo]

My purpose is to create a bi-dimensional array in which
self-replicating cells exist, in certain conditions they replicate by
theirselves, and everything has to be fully dynamical, for I create
one only cell in the time of compilation. That's why I can't limit the
number of tasks I can allocate memory for.

Thanks for your support.

carlos.

Problem with tasks

[Magik]

Hello.

1. Proces_Alarmu.Start -> Yes OK!
2. Proces_Alarmu.Stop -> Yes OK!
But
3. Proces_Alarmu.Start - Why does not start again exercise?

task Proces_Alarmu is
      entry Start;
      entry Stop;
   end Proces_Alarmu;

task body Proces_Alarmu is
   begin
      accept Start;
            loop
             select
                accept Stop;
                exit;
         or
            delay 1.0;
            end select;
put("test");
      end loop;
   end Proces_Alarmu;

Programming in Windows Gnat 3.13

Re: Problem with tasks

[Frank J. Lhota]

"Magik" <dormar00@poczta.onet.pl> wrote in message
news:chc076$i96$1@nemesis.news.tpi.pl...
> Hello.
>
> 1. Proces_Alarmu.Start -> Yes OK!
> 2. Proces_Alarmu.Stop -> Yes OK!
> But
> 3. Proces_Alarmu.Start - Why does not start again exercise?

Because Proces_Alarmu was not written that way. After the Stop entry was
called, the Proces_Alarmu task exits the loop and finishes its body of code.
Task entries do NOT work like external "goto" statements: if you want
Proces_Alarmu to service the Start entry, then the code for Proces_Alarmu
must be able to get to an "accept Start" call.

Whenever one has a problem of this sort, it is advisable to include a
description of how you want the task to behave. Assuming that Proces_Alarmu
is supposed to alternately accept Start and Stop entries, and print "test"
once a second until the Stop entry was called, then Proces_Alarmu could be
written like this:

task Proces_Alarmu is
   entry Start;
   entry Stop;
end Proces_Alarmu;

task body Proces_Alarmu is
begin
   For_Each_Start_Stop:
   loop
      accept Start;
      Until_Stop:
      loop
         select
            accept Stop;
            exit;
         or
            delay 1.0;
            put("test");
         end select;
      end loop Until_Stop;
   end loop For_Each_Start_Stop;
end Proces_Alarmu;

Re: Problem with tasks

[Magik]

Thank you.

Re: Problem with tasks

[Pascal Obry]

"Magik" <dormar00@poczta.onet.pl> writes:

Others have answered your question, but:

> Programming in Windows Gnat 3.13

Be sure to upgrade to 3.15p. 3.13 is a prehistorical release :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595