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 11:52:02 PST Path: supernews.google.com!sn-xit-02!sn-east!sn-xit-03!supernews.com!hermes.visi.com!news-out.visi.com!nycmny1-snh1.gtei.net!news.gtei.net!newsfeed.mathworks.com!cyclone.swbell.net!nnrp3.sbc.net.POSTED!not-for-mail From: "Pat Rogers" Newsgroups: comp.lang.ada References: <39ADAE51.30550667@mtws.visicom.com> <39ADD3A3.381DEF17@ix.netcom.com> <39AF20CE.FDBDFFFE@mtws.visicom.com> <39AF2DEC.71D8B897@ix.netcom.com> <39B52DFC.6EF265D3@ix.netcom.com> Subject: Re: Ada 95 tasking problems with Ada 83 code X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Message-ID: Date: Tue, 5 Sep 2000 13:51:36 -0500 NNTP-Posting-Host: 208.191.184.67 X-Complaints-To: abuseswbell.net X-Trace: nnrp3.sbc.net 968179913 208.191.184.67 (Tue, 05 Sep 2000 13:51:53 CDT) NNTP-Posting-Date: Tue, 05 Sep 2000 13:51:53 CDT Organization: SBC Internet Services Xref: supernews.google.com comp.lang.ada:499 Date: 2000-09-05T13:51:36-05:00 List-Id: "Richard Riehle" wrote in message news:39B52DFC.6EF265D3@ix.netcom.com... > > 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. I'm influenced by the Real-Time Systems Group at York, where both have received quite a bit of thought. :-) All kidding aside, I find some of the dynamic ones, such as EDF, to be simpler. > 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." Humm. Surely liveness is a property independent of the number of tasks involved. A "correct" concurrent program should work no matter how many tasks exist. The "finite progress assumption" tells use that all tasks in a correct concurrent program will eventually run. I think what you're saying is that a large number of interacting tasks more likely justifies an analysis of the interactions -- a very reasonable assertion -- such that some idea of the effective throughput can be determined. This determination can then be used to critique the design. If so, that seems very reasonable. Perhaps I have a design in the back of my mind that is biasing my perception of the effect of the number of tasks. If most of the tasks are different (i.e. of a different type) then yes, the idea that they will all be ready to run at a critical instant seems unlikely, and some idea of the throughput seems worthy of analysis. On the other hand, I often like to have pools of tasks, all of the same type, ready to do the work that becomes available. In such a case it might not be unusual for there to be quite a few created, although most might not be running at any given moment. As you say, increasing the pool size can then be a way of increasing throughput. > 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. In truth I was really just thinking of the fact that most general-purpose tasking system implemenations use dynamic data structures whose performance degrade as they grow in length. > > 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. Certainly for a real-time system. But for "just" a concurrent program, I think a full schedulability analysis is overkill. Pat