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 12:33:38 PST Path: supernews.google.com!sn-xit-02!sn-east!supernews.com!news-feed.riddles.org.uk!newsfeed.direct.ca!look.ca!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> <39B542BE.E0AFA887@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 14:33:08 -0500 NNTP-Posting-Host: 208.191.184.67 X-Complaints-To: abuseswbell.net X-Trace: nnrp3.sbc.net 968182406 208.191.184.67 (Tue, 05 Sep 2000 14:33:26 CDT) NNTP-Posting-Date: Tue, 05 Sep 2000 14:33:26 CDT Organization: SBC Internet Services Xref: supernews.google.com comp.lang.ada:502 Date: 2000-09-05T14:33:08-05:00 List-Id: "Richard Riehle" wrote in message news:39B542BE.E0AFA887@ix.netcom.com... > > Pat Rogers wrote: > > > "Richard Riehle" wrote in message > > news:39B52DFC.6EF265D3@ix.netcom.com... > > > > > 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. > > OK. I will agree with that. We simply had different models immediately > in mind. The "pool of tasks" design will be different from a real-time model > where each task performs some unique action, and deadlines and schedulability > are critical. Also, we are still not sure what Wayne is doing, so he has some > work to do in deciding which approach is more appropriate. I am sure you > agree, though, that anyone planning a design using concurrent tasks should > have a little familiarity with the issues related to scheduling, even when > using a pool of similar tasks, especially if those tasks are communicating with each > other. Yes, definitely, if by scheduling you mean the issues of deadlock, indefinite postponement, livelock, and so on -- i.e., what it means for a concurrent program to be "correct" -- as well as the ramifications of task interactions (e.g. context switching) on performance. Absent deadlines, though, I think those are sufficient (as if those were simple subjects!). A pleasure as always, pat