From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.236.110.2 with SMTP id t2mr1963419yhg.58.1413483520645; Thu, 16 Oct 2014 11:18:40 -0700 (PDT) X-Received: by 10.140.91.4 with SMTP id y4mr36578qgd.14.1413483520603; Thu, 16 Oct 2014 11:18:40 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!dc16no3327312qab.1!news-out.google.com!u5ni5qab.1!nntp.google.com!dc16no3327308qab.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 16 Oct 2014 11:18:40 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=93.37.88.198; posting-account=9fwclgkAAAD6oQ5usUYhee1l39geVY99 NNTP-Posting-Host: 93.37.88.198 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: dynamic vs static tasks allocation From: mockturtle Injection-Date: Thu, 16 Oct 2014 18:18:40 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 3742 X-Received-Body-CRC: 1334577493 Xref: news.eternal-september.org comp.lang.ada:22533 Date: 2014-10-16T11:18:40-07:00 List-Id: 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 c= reate tasks dynamically with new operator or just statically? > =20 > Which is way is recommended and why even bother allocating dynamically? Nice question... I guess that the answer is a definitive "it depends." =20 Just my 2.0e-2...=20 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 somethin= g 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 "declar= e" 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; =20 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 typ= ical 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-serve= r that takes care of all the dialogue with the client. In this case you ha= ve two possible macro-approaches: create the sub-server task at runtime wit= h "new" or keep a "pool" of static sub-servers that serve the requests, the= n go back to sleep, waiting for a new request. I expect the second solutio= n to be more efficient (in terms of time required to reply to the client) s= ince you avoid the overhead related with task creation. (We are on the bo= rder 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 al= low 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 ke= ep a task "inside" a record, but if you declare a component of task type th= e record will be limited (it does not make any sense to copy a record). Si= nce having the record limited was a problem, I used an access to task and t= his required to have the task created dynamically. (Sorry, I do not rememb= er the details, it was too much time ago). Hope this helps. Riccardo