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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1c3d4536a687b7b0 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2000-09-05 10:45:40 PST Path: supernews.google.com!sn-xit-02!sn-east!sn-xit-uk!supernews.com!193.162.153.122.MISMATCH!news.tele.dk!128.230.129.106!news.maxwell.syr.edu!feeder.via.net!newsfeed1.earthlink.net!newsfeed2.earthlink.net!newsfeed.earthlink.net!news.mindspring.net!firehose.mindspring.com!not-for-mail From: Richard Riehle Newsgroups: comp.lang.ada Subject: Re: Ada 95 tasking problems with Ada 83 code Date: Tue, 05 Sep 2000 10:31:40 -0700 Organization: MindSpring Enterprises Message-ID: <39B52DFC.6EF265D3@ix.netcom.com> References: <39ADAE51.30550667@mtws.visicom.com> <39ADD3A3.381DEF17@ix.netcom.com> <39AF20CE.FDBDFFFE@mtws.visicom.com> <39AF2DEC.71D8B897@ix.netcom.com> NNTP-Posting-Host: d1.8a.d1.14 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 5 Sep 2000 17:43:57 GMT X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en Xref: supernews.google.com comp.lang.ada:497 Date: 2000-09-05T17:43:57+00:00 List-Id: Pat Rogers wrote: > "Richard Riehle" wrote in message > news:39AF2DEC.71D8B897@ix.netcom.com... > > > > > Reminder: you still need to take a look at RMA if you have 100 > concurrent tasks. > > I confess I don't see why. Surely the number of tasks, by itself, > doesn't require a schedulability analysis. (There may very well be > deadlines associated, but that hasn't been indicated as far as I > know.) Absent deadlines, then this is "just" a concurrent program, in > which case the issues are maximizing throughput and ensuring liveness. > Liveness isn't a function of the number of tasks, so I don't see the > connection. > > On the other hand, let's say there are deadlines. In that case, a > static-priority preemptive scheduling scheme may not be the right > approach (e.g., RMA). Perhaps a dynamic scheme might be best -- say > Earliest Deadline First (which is optimal too). In other words, it > seems to me that that the info so far -- 100 tasks -- isn't sufficient > to require use of any schedulability analysis, RMA or otherwise. > > (Sure, the more tasks one has the more likely a general-purpose > tasking system is to bog down, but that is a separate issue I would > think.) > > Of course you know these things, so what am I missing? Pat, I am probably just an RMA bigot and believe everyone who is doing anything with tasking should have a rudimentary undestanding of it. Also, I see RMA as a larger issue than the simple static scheduling of its beginnings. Most treatments of the subject, including the Briand and Roy work I cited earlier, do include treatments of both static and dynamic scheduling. However, I believe one should understand the static models before moving on to the dynamic ones. As far as liveness and the number of tasks, if there are truly one-hundred tasks in this design, it is hard to imagine that they will all be ready to do their work at the required instant unless there is some kind of schedulability scheme. This can be a really simple scheme or a really sophisticated one. The answer to your question is in the last paragraph of your posting. When there a lot of tasks in a design, absent a good scheduling model (dynamic or static), there is an increased probability they will "bog down." The number of tasks may not always be a direct indicator of the need for schedulability schemes, but, as you note, as the number of tasks increases, there is a potential for them to block each other at inopportune times and bog down the system. If the tasks are communicating, this becomes even more interesting. If every task is executing at the same priority, and there is a lot of rendezvous occurring, one can spend many entertaining hours trying to fine-tune the performance of the design. All that being said, we don't know enough details of Wayne's design to make absolute pronouncements about how he should proceed, but I think you would agree that anyone designing a task-based system ought to have some awareness of the issues related to schedulability. Richard