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: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: Realtime Ada Conferences Date: 1996/03/28 Message-ID: #1/1 X-Deja-AN: 144704959 references: <4jdcfd$7gc@news2.delphi.com> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-03-28T00:00:00+00:00 List-Id: tmoran says " Is it just me, or does calling this a 'simulated context switch' remind others of Orwellian language redefinition. A 'context switch' means a switch to a different Ada task. If an implementation wants to include switching OS threads, or rebooting to a different OS, or switching to a different computer in orbit on the other side of the globe, fine, but don't redefine that as a context switch and anything else as 'simulated'. Especially in a context discussing whether a 'context switch' takes more than 20 us in a language designed for embedded systems." well it's probably just you, since lots of people use the terminology of "real" threads and "simulated" threads in the context of operating systems, but anyway there is no point in worrying about terminology here, call them blue threads and red threads (or if you like follow the NT terminology and call them threads and fibres). The important point is that when you are using Ada in the context of an operating system that supports threads, like typical threaded unices of today, the difference between the red and blue threads is very considerable, and you need to be sure that you are comparing apples and oranges. The 20 usec figure should be easy to achieve on any modern machine, but if you are using OS threads, you will often find that the OS overhead on a context switch of the simplest kind, even on a 200 MIPS machine, way exceeds this figure. Now we can all see that 4,000 instructoins is rather a lot for a simple context switch, let alone the 40,000 that we often see on real time unices. My feeling is that the 20usec figure is sort of inbetween, for an embedded application it is high, you should be able to do a CS in far less than 4,000 instructions if you don't have an OS intefering with you, but in the context of a real-time OS, the 20us fifure will often be hard to achieve. Of course from th Ada point of view, there can be a huge difference between red and blue threads. If you are using OS threads, then you can do real overlapped operations at the OS leve, if you are not using OS threads, you can easily find the entire program blocked by the action of a single Ada task, which is not disallowed by Ada semantics, but might very well not be what is desired. By the way, I do not agree that Ada 95 was "designed for embedded systems", if this were true, the presence of COBOL-style picture editing, and many other facilities would be a puzzle. Ada 95 is a general purpose language, which is suitable for many tasks, including embedded systems, and the design of the language reflects this more general viewpoint.