* dynamic vs static tasks allocation @ 2014-10-16 17:25 Stribor40 2014-10-16 18:18 ` mockturtle ` (2 more replies) 0 siblings, 3 replies; 5+ messages in thread From: Stribor40 @ 2014-10-16 17:25 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: dynamic vs static tasks allocation 2014-10-16 17:25 dynamic vs static tasks allocation Stribor40 @ 2014-10-16 18:18 ` mockturtle 2014-10-16 18:41 ` Adam Beneschan 2014-10-16 18:45 ` Jeffrey Carter 2014-10-17 0:07 ` Dennis Lee Bieber 2 siblings, 1 reply; 5+ messages in thread From: mockturtle @ 2014-10-16 18:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: dynamic vs static tasks allocation 2014-10-16 18:18 ` mockturtle @ 2014-10-16 18:41 ` Adam Beneschan 0 siblings, 0 replies; 5+ messages in thread From: Adam Beneschan @ 2014-10-16 18:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: dynamic vs static tasks allocation 2014-10-16 17:25 dynamic vs static tasks allocation Stribor40 2014-10-16 18:18 ` mockturtle @ 2014-10-16 18:45 ` Jeffrey Carter 2014-10-17 0:07 ` Dennis Lee Bieber 2 siblings, 0 replies; 5+ messages in thread From: Jeffrey Carter @ 2014-10-16 18:45 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: dynamic vs static tasks allocation 2014-10-16 17:25 dynamic vs static tasks allocation Stribor40 2014-10-16 18:18 ` mockturtle 2014-10-16 18:45 ` Jeffrey Carter @ 2014-10-17 0:07 ` Dennis Lee Bieber 2 siblings, 0 replies; 5+ messages in thread From: Dennis Lee Bieber @ 2014-10-17 0:07 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-10-17 0:07 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-10-16 17:25 dynamic vs static tasks allocation Stribor40 2014-10-16 18:18 ` mockturtle 2014-10-16 18:41 ` Adam Beneschan 2014-10-16 18:45 ` Jeffrey Carter 2014-10-17 0:07 ` Dennis Lee Bieber
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox