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=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ee6e394aae0270ff X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-04 15:58:16 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!zeus.visi.com!news-out.visi.com!green.octanews.net!news.octanews.net!news-xfer.cox.net!peer01.cox.net!cox.net!border3.nntp.aus1.giganews.com!intern1.nntp.aus1.giganews.com!nntp.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Sun, 04 Jan 2004 17:58:14 -0600 Date: Sun, 04 Jan 2004 18:58:14 -0500 From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: How to calculate optimum task size? References: <_W0Kb.1095$%L6.628@nwrdny01.gnilink.net> In-Reply-To: <_W0Kb.1095$%L6.628@nwrdny01.gnilink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 24.34.214.193 X-Trace: sv3-7SD9OdSg70iNKNT96h04sbVJZW/ZWTdpjrvRFEk1H4j0IQxwhwfsABRW3JknsQ3VMMUTsqLQGv8oKay!YwvQ/jRmnS7C4EBckmHhSzcapVvYdtAaMpLMxYUwd2WeL3a4yolvBVfz1Mt54w== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: archiver1.google.com comp.lang.ada:4108 Date: 2004-01-04T18:58:14-05:00 List-Id: Stephane Richard wrote: > I'm not quite sure what you mean by Optimal task size. if you're looking > for the best size as far as speed is concerned, in my past I've found that > giving tasks a size of 2^X somehow works faster. hence 1024 instead 1000 > bytes for example. > > If you're wondering if the task size influences what the task can handle as > far as capacity goes I'll let the gurus here answer that part of it :-). I could probably spend three years trying to answer that, and not cover all the important issues. In safety-critical the usual approach is to have a fixed number of tasks, and for each of those tasks to have a call tree with no recursion. Each call has should have fixed stack requirements. That way you can compute the maximum possible stack size requirement for each task. Of course, you also want to have a limit on heap allocations. Some organizations have rules that require no heap allocations. The rules I prefer allow explicit heap allocations, but only during initialization. If you really need to solve this problem get some books on real-time and safety-critical programming, then choose a set of design tools that you will use to do the analysis. (It is painful to keep track of the requirements as you make modifications, fix bugs, etc.) Does all this double or triple the cost of the software? Yes, welcome to the world of hard-real time and safety-critical software. (What makes real-time software hard real-time? The difficultly of meeting all the requirements. ;-) -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush