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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,67c50b972ca3b532 X-Google-Attributes: gid103376,public From: Ed Falis Subject: Re: Realtime Ada Conferences Date: 1996/03/29 Message-ID: <315BF72D.8A2@east.thomsoft.com>#1/1 X-Deja-AN: 144857254 sender: news@thomsoft.com references: <4j9j9f$620@hacgate2.hac.com> <315998AC.67AA@thomsoft.com> content-type: text/plain; charset=us-ascii organization: Thomson Software Products mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 2.0 (Win95; I) Date: 1996-03-29T00:00:00+00:00 List-Id: Robert Dewar wrote: . > > Note that these context switch times are for simulated context switching > (i.e. threads simulation), rather than for use of operating systems > threads. Of course that's all you will get on DOS/Windows type > environments, so that's certainly not a criticism! Well, for the sake of accuracy, as Robert and I agree: this is not "simulated threads" by any definition I can think of. It's Ada intertask communication in a "bare machine environment", where the closest thing to a thread is an Ada task mapped over the hardware. It's the equivalent of say, a task or thread under VRTX or VXWorks or another RTOS, except that an Ada bare executive tends to have less functionality. If you're talking mapping Ada tasks over threads, the biggest performance limitation tends to be the characteristics of the underlying threads implementation, as Robert pointed out. But isn't that to some extent the price to paid for a richer computational environment? - Ed -- Ed Falis Thomson Software falis@thomsoft.com (617) 221-7341 ======================================================== Ideological disarmament: a koan for the 21st century ========================================================