Re: Realtime Ada Conferences

[dewar@cs.nyu.edu (Robert Dewar)]

tmoran says

"<flame on>
  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.