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 19:38:50 PST Path: supernews.google.com!sn-xit-02!sn-east!supernews.com!news-feed.riddles.org.uk!newsfeed.direct.ca!look.ca!howland.erols.net!nntp.flash.net!mercury.cts.com!thoth.cts.com!not-for-mail From: Wayne Lydecker Newsgroups: comp.lang.ada Subject: Re: Ada 95 tasking problems with Ada 83 code Date: Tue, 05 Sep 2000 19:38:59 -0700 Organization: CTSnet Internet Services Message-ID: <39B5AE43.D2EA477C@mtws.visicom.com> References: <39ADAE51.30550667@mtws.visicom.com> <39ADD3A3.381DEF17@ix.netcom.com> <39AF20CE.FDBDFFFE@mtws.visicom.com> <39AF2DEC.71D8B897@ix.netcom.com> <39B046AE.A05C82AA@mtws.visicom.com> <39B5298A.177B7C15@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: thoth.cts.com 968207915 49374 63.202.233.170 (6 Sep 2000 02:38:35 GMT) X-Complaints-To: abuse@cts.com X-Mailer: Mozilla 4.73 [en]C-CCK-MCD NSCPCD47 (Win98; U) X-Accept-Language: en Xref: supernews.google.com comp.lang.ada:509 Date: 2000-09-05T19:38:59-07:00 List-Id: Richard Riehle wrote: > > Wayne Lydecker wrote: > > > > > The original developers of our software were task and generic happy (some > > generics are up to three levels deep). There is no valid reason that it has > > 100 tasks and I'd like to strip it down to a half dozen or so. > > Wayne, > > Be careful about this kind of decision. All too often a designer intuits that less > tasks will be more efficient that more. In fact, the ideal for a task-based design > on a single processor, is that every task will always be immediately available to > do its work. This ideal is frequently unachievable, but one can strive for it. > > A corollary of the above statement is that most tasks will spend most of their > life waiting for something to do. Once that something is actually done, they > will suspend until asked to do it again. This means that each task should do the > absolute minimum amount of work. In particular, keep each rendezvous sparse > to prevent blocking other important actions. > > It is not unusual, in fine-tuning a task-based design, to increase the number of tasks, > making each one leaner, instead of reducing the number of tasks. > > Of course, it is still essential to do the mathematics on this before making such a > decision. > You must consider context-switching time, priorities, and a whole host of other related > > issues before simply changing the number of tasks in the design. Also, with Ada 95, > many chores previously handed off to an active task can be more efficiently executed > through a protected type. If you have not looked at protected types, this would be a > good time to do so. For a good example of a simple protected variable, see Norman > Cohen's book, Ada As A Second Language, 17.4.4., page 831, from McGraw-Hill, > or, even better, get a copy of Concurrency in Ada, by Alan Burns and Andy Wellings. > > Hope this helps, > > Richard Riehle That was exactly what I had in mind. The majority of our tasks (~75) are used to synchronize access to the databases. Most of the rest are for alarm clocks, which were poorly implemented. I agree 100% that a good tasking model works fine for 100+ tasks, but when the tasks have infinite loops with a "delay duration'small" to allow a context switch for a type of "round robin" scheduling, it's time for a redesign (which is really what I want to do). -- Wayne.