dynamic vs static tasks allocation

dynamic vs static tasks allocation

[Stribor40]

If you know ahead of time how many tasks will be needed is it better to create tasks dynamically with new operator or just statically?

Which is way is recommended and why even bother allocating dynamically?

Re: dynamic vs static tasks allocation

[mockturtle]

On Thursday, October 16, 2014 7:25:51 PM UTC+2, Stribor40 wrote:
> If you know ahead of time how many tasks will be needed is it better to create tasks dynamically with new operator or just statically?
>  
> Which is way is recommended and why even bother allocating dynamically?

Nice question... I guess that the answer is a definitive "it depends."  

Just my 2.0e-2... 

As a general rule, I always prefer to avoid dynamic allocation, so I prefer to allocate the task statically.  BTW, please note that if you do something like

   task type Foo;

   declare
     Worker : Foo; -- Worker starts here
   begin
     -- Worker is running
     ... do something ...
   end;

task Worker is started "dynamically" when the execution reaches the "declare" block, without using "new."  I do not know if your idea of "dynamically" includes this example or not.  Also note that in this case

   procedure Bar(N: Positive) is
     Workers : array (1..N) of Foo;  
   begin
      --  N workers running
      ... do something;
   end Bar;

the number of tasks is determined dynamically at runtime.


Another reason for having static tasks is (in general) efficiency.  The typical example is a web server that waits for connections on the port 80 and every time a connection arrives, it hands the new connection to a sub-server that takes care of all the dialogue with the client.  In this case you have two possible macro-approaches: create the sub-server task at runtime with "new" or keep a "pool" of static sub-servers that serve the requests, then go back to sleep, waiting for a new request.  I expect the second solution to be more efficient (in terms of time required to reply to the client) since you avoid the overhead related with task creation.  (We are  on the border of the sin of "preventive optimization" here, a more precise analysis should be done on a case-by-case basis).

Moreover, if I remember correctly, there are some "profiles" that do not allow for the dynamic creation of tasks, so all your tasks must be "static."

Finally, why using "new" for creating new tasks?  Well, once I needed to keep a task "inside" a record, but if you declare a component of task type the record will be limited (it does not make any sense to copy a record).  Since having the record limited was a problem, I used an access to task and this required to have the task created dynamically.  (Sorry, I do not remember the details, it was too much time ago).

Hope this helps.

Riccardo

Re: dynamic vs static tasks allocation

[Adam Beneschan]

On Thursday, October 16, 2014 11:18:41 AM UTC-7, mockturtle wrote:

> As a general rule, I always prefer to avoid dynamic allocation, so I prefer to allocate the task statically.  BTW, please note that if you do something like
> 
> 
> 
>    task type Foo;
> 
>    declare
>      Worker : Foo; -- Worker starts here
>    begin
>      -- Worker is running
>      ... do something ...
>    end;
> 
> task Worker is started "dynamically" when the execution reaches the "declare" block, without using "new."  I do not know if your idea of "dynamically" includes this example or not.  Also note that in this case
> 
>    procedure Bar(N: Positive) is
>      Workers : array (1..N) of Foo;  
>    begin
>       --  N workers running
>       ... do something;
>    end Bar;
> 
> the number of tasks is determined dynamically at runtime.

Also note that in the above examples, the block which declares the task (in the first example) or the procedure Bar (in the second example) will not be allowed to exit until the task(s) are done (technically, until they are "terminated").  If the block or Bar uses "new" to start the task, the block or Bar can complete while the task is still running, as long as the access type used for "new" is not declared inside the block or Bar (technically, the ultimate ancestor of the access type).  That may be another reason to use "new" to create a task.

                               -- Adam

Re: dynamic vs static tasks allocation

[Jeffrey Carter]

On 10/16/2014 10:25 AM, Stribor40 wrote:
> If you know ahead of time how many tasks will be needed is it better to
> create tasks dynamically with new operator or just statically?
> 
> Which is way is recommended and why even bother allocating dynamically?

There are actually 3 ways to create tasks:

1. Statically, in a pkg or the main procedure:

package body P is
   task Foo is

2. Dynamically without access types, using block statements or subprograms:

task type Foo;

type Foo_List is array (Positive range <>) of Foo;

procedure P (Num_Workers : in Positive) is
   Worker : Foo_List (1 .. N);

3. Dynamically with access types, using new:

task type Foo;
type Foo_Ptr is access Foo;

Worker : Foo_Ptr;
...
Worker := new Foo;

1 and 2 are often both considered static allocation.

The trouble with 3, as with any use of access types, is memory management. With
access-to-task types, you also have to be sure the task has terminated before
freeing it. For these reasons, I avoid 3 whenever possible.

-- 
Jeff Carter
"I blow my nose on you."
Monty Python & the Holy Grail
03

Re: dynamic vs static tasks allocation

[Dennis Lee Bieber]

On Thu, 16 Oct 2014 10:25:50 -0700 (PDT), Stribor40 <ikamzic@gmail.com>
declaimed the following:

>If you know ahead of time how many tasks will be needed is it better to create tasks dynamically with new operator or just statically?
>
>Which is way is recommended and why even bother allocating dynamically?

	Avionics stuff creates all processes (and memory structures) during
initialization -- the only reason for dynamic task creation would be if the
/number of specific tasks/ is determined from a startup configuration file
-- otherwise they are essentially statically determined.

	But for something like a simulation -> simplistic example: say animal
interaction -- creating a dynamic task each time an animal is "born" might
be a scheme (though such are likely more easily run using a before/after
array of the critters in a loop -- not to mention having to "teach" the new
one about the rest of the pack).

	Knowing how many are needed (without a configuration file) seems, to
me, to imply declaring a fixed array of them at compile time.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/