Re: Realtime Ada Conferences

Re: Realtime Ada Conferences

[Robert Dewar]

Jeff said

"Ada 95 does not really solve the realtime problem because
vendors are not forced to deliver the Ada 95 realtime
extensions."

I think this is a bogus worry. Sure some compiler intened only as a COBOL
replacement might implement the info systems annex and not the rt annex,
but any compiler even vaguely intended for the rt market will have to
implement the RT annex, the market will ensure this much more effectively
than any rule in the standard!

Realtime Ada Conferences

[Jeff T. Stevenson]

Are any of the Ada conferences, e.g., Tri-Ada planning on 
addressing the topic of realtime Ada applications this year?

It seems from previous trips to Tri-Ada that realtime issues
are not covered well.

Is anything being done to allow Ada compiler vendors to 
produce compilers that have task context switch times
in the 20 us range?  It seems that most compiler vendors
are not able to comply with the Ada83 tasking model
and provide realtime context switching capabilities.

Ada 95 does not really solve the realtime problem because
vendors are not forced to deliver the Ada 95 realtime
extensions.

Where and when is Tri-Ada this year?  Does the agenda 
get posted here?

Jeff Stevenson
jtstevenson@ccgate.hac.com

Re: Realtime Ada Conferences

[Larry Howard]

In article <4j9j9f$620@hacgate2.hac.com> jts@ipld01.hac.com
(Jeff T. Stevenson) writes:

<snip>
>Is anything being done to allow Ada compiler vendors to 
>produce compilers that have task context switch times
>in the 20 us range?  It seems that most compiler vendors
>are not able to comply with the Ada83 tasking model
>and provide realtime context switching capabilities.

Yes, they're called faster computers. :-) Seriously, the
implication I got from what you said is that Ada compilation
systems without 20 usec context switching times do not provide
realtime context switching capabilities.  Many realtime
applications do not require this level of performance and are
nonetheless realtime.  "Realtime" implies to me predictable
timing behavior, and not some arbitrary level of performance.

>Ada 95 does not really solve the realtime problem because
>vendors are not forced to deliver the Ada 95 realtime
>extensions.

That vendors aren't forced to deliver an annex is precisely
the idea of annexes.  It's their targeted marketplace that
should determine whether a vendor supplies a given annex and
at what level of performance.  Besides, I'm only familiar with
one hard performance requirement in the Real-Time Systems
Annex, and that is for clock resolution, which incidentally is
20 usecs or better.  This certainly stands to affect task
periodicities, but not context switching times.

Am I missing something?
--
Larry Howard
Software Engineering Institute, Carnegie Mellon University
lph@sei.cmu.edu (NeXT Mail OK)      (412) 268-6397

Re: Realtime Ada Conferences

[tmoran]

>Is anything being done to allow Ada compiler vendors to
>produce compilers that have task context switch times
>in the 20 us range?  It seems that most compiler vendors
  I just ran two tasks, each containing
    for i in 1 .. 10000 loop delay 0.0;end loop;
  That presumably generated 20,000 context switches and it took
0.44 seconds on my Pentium 60, giving 22 mics/context switch.
Is that what you meant?

Re: Realtime Ada Conferences

[Brad Balfour]

In article <4j9j9f$620@hacgate2.hac.com>, jts@ipld01.hac.com (Jeff T.
Stevenson) wrote:

>Are any of the Ada conferences, e.g., Tri-Ada planning on 
>addressing the topic of realtime Ada applications this year?
>
>It seems from previous trips to Tri-Ada that realtime issues
>are not covered well.
[snip]
>Where and when is Tri-Ada this year?  Does the agenda 
>get posted here?

Tri-Ada '96 will be held on December 3 - 7, 1996 at the
Philadelphia Marriott, in Philadelphia, PA.

Information on the conference has been/will be posted to comp.lang.ada as
well as already being available on the Tri-Ada '96 home page:
     http://www.acm.org/sigada/conf/ta96/

Real time issues and experences in real-time use of Ada will be a featured
topic -- as it has been in past years. Much of the community of Ada
software developers are working on embedded and real-time systems and
Tri-Ada remains a place for them to gather and exchange information and
tips.

Other major topics/themes include:
 * Exploiting the power of OOP combined with
     true multi-threading
 * Gluing together software written in C, C++, Cobol,
     Fortran, etc.
 * Creating distributed and client/server software
 * Producing WWW applications and Java bytecode
 * Achieving enhanced software reuse through OOP and
     hierarchical libraries of packages
 * Enhancing real-time power and performance via
     protected types and multi-threaded tasks

If you have questions on the conference program, you may contact the
Program Chair, Anthony Gargaro (gargaro@sw-eng.falls-church.va.us).
General conference questions may be directed to the Conference Chair, Dr.
Jorge L. Diaz-Herrera (jdiaz@sei.cmu.edu).

To get on the (paper) mailing list for Tri-Ada 96 registration and
conference information you may call 1-800-338-5365.
--
Brad Balfour                            SIGAda WWW Server
Tri-Ada Publicity Chair                   http://www.acm.org/sigada/
(703) 277-6767                          and also try:
bbalfour@acm.org                          http://lglwww.epfl.ch/Ada/

Re: Realtime Ada Conferences

[Ed Falis]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

Jeff T. Stevenson wrote:
> 
> 
> Is anything being done to allow Ada compiler vendors to
> produce compilers that have task context switch times
> in the 20 us range?  It seems that most compiler vendors
> are not able to comply with the Ada83 tasking model
> and provide realtime context switching capabilities.
> 

Jeff,

I think your info about context switching time is out of date.  Here's 
some sample PIWG data for our ActivAda Realtime product, an Ada 83 
compiler for 32 bit Intel x86 processors.  The benchmarks were run with 
checks on and optimizations on.  The target is a 75MHz 80486 DX4.

But like another person said, it's mostly a matter of processor speed, 
and this is certainly not the fastest thing we or others have.  The real 
issue is predictability.



-- 
Ed Falis	
Thomson Software   falis@thomsoft.com	(617) 221-7341
========================================================
Ideological disarmament: a koan for the 21st century
========================================================

[-- Attachment #2: tasks.txt --]
[-- Type: text/plain, Size: 2419 bytes --]



Test Name:   T000001                         Class Name:  Tasking
CPU Time:       19.59  MICROSECONDS          plus or minus      0.979
Wall/CPU:        1.00  ratio.                Iteration Count:   51200
Test Description:
 Minimum rendezvous, entry call and return time 
 1 task 1 entry , task inside procedure 
 no select 



Test Name:   T000002                         Class Name:  Tasking
CPU Time:       22.58  MICROSECONDS          plus or minus      1.129
Wall/CPU:        1.00  ratio.                Iteration Count:   51200
Test Description:
 Task entry call and return time measured
 One task active, one entry in task, task in a packae 
 no select statement 



Test Name:   T000003                         Class Name:  Tasking
CPU Time:       21.11  MICROSECONDS          plus or minus      1.056
Wall/CPU:        1.00  ratio.                Iteration Count:   51200
Test Description:
 Task entry call and return time measured
 Two tasks active, one entry per task, tasks in a package 
 no select statement 



Test Name:   T000004                         Class Name:  Tasking
CPU Time:       34.78  MICROSECONDS          plus or minus      1.739
Wall/CPU:        1.00  ratio.                Iteration Count:   51200
Test Description:
 Task entry call and return time measured
 One tasks active, two entries, tasks in a package 
 using select statement 



Test Name:   T000005                         Class Name:  Tasking
CPU Time:       23.30  MICROSECONDS          plus or minus      1.165
Wall/CPU:        1.00  ratio.                Iteration Count:   64000
Test Description:
 Task entry call and return time measured
 Ten tasks active, one entry per task, tasks in a package 
 no select statement 



Test Name:   T000006                         Class Name:  Tasking
CPU Time:       40.16  MICROSECONDS          plus or minus      2.008
Wall/CPU:        1.00  ratio.                Iteration Count:   32000
Test Description:
 Task entry call an return time measurement
 One task with ten entries , task in a package 
 one select statement, compare to T000005 



Test Name:   T000008                         Class Name:  Tasking
CPU Time:       53.87  MICROSECONDS          plus or minus      2.693
Wall/CPU:        1.00  ratio.                Iteration Count:   25600
Test Description:
 Measure the average time o pass an integer 
 from a producer task through a buffer task 
 to a consumer task 

Re: Realtime Ada Conferences

[Robert Dewar]

Larry said

"<snip>
>Is anything being done to allow Ada compiler vendors to
>produce compilers that have task context switch times
>in the 20 us range?  It seems that most compiler vendors
>are not able to comply with the Ada83 tasking model
>and provide realtime context switching capabilities.

Yes, they're called faster computers. :-) Seriously, the
implication I got from what you said is that Ada compilation
systems without 20 usec context switching times do not provide
realtime context switching capabilities.  Many realtime
applications do not require this level of performance and are
nonetheless realtime.  "Realtime" implies to me predictable
timing behavior, and not some arbitrary level of performance."

Actually more and more realtime systems are being built on top of
so-called real-time systems like NT, Lynx, Chorus, or even just
Vanilla unix with Posix interfaces. I say "so-called", because
if your idea of real-time is 20 microsecond context switch (*)
then you will find that the OS already has lost the battle by
a significant factor. But, as Larry said, applications can
certainly be real-time without requiring 20 usec cst.

(*) 20 usec seems slow to me, when I was writing real-time operating
systems for Honeywell on 4MHz 8080 systems, we were aiming at better
context switching times than this :-)

Re: Realtime Ada Conferences

[Robert Dewar]

Ed Falis said

"I think your info about context switching time is out of date.  Here's
some sample PIWG data for our ActivAda Realtime product, an Ada 83
compiler for 32 bit Intel x86 processors.  The benchmarks were run with
checks on and optimizations on.  The target is a 75MHz 80486 DX4.
"

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!

But you need to be very careful about comparisons here. One of our GNAT
customers was surprised to find that GNAT context switching time was
much better on SunOS than on Solaris -- yes of course, because on Solaris
we use the operating system threads, which are supposedly "lightweight"
but still slow, and on SunOS, we do our own simulated context switching.

Most people want to use real threads when running over an OS that has
real threads, and for example, I am sure that the new Thompson compiler
for Win NT will have this capability. 

We actually can run Solaris with simulated threads as well, but for
simplicity only support the "real" threads version.

A nice capability in the old Alsys technology, which I would expect to
carry over to the new Thompson technology is a very flexible way of
spefiying mapping tasks to threads, with 1-1 (use all OS threads)
and all-1 (simulate all threads) just being two extremes of a very
flexible way of specifying the mapping. I will let Ed say more
about this!

Robert Dewar
Ada Core Technlogies

P.S. there are two Robert Dewar's around, the general Ada gadfly who
comments on all sorts of CLA issues, and the president of ACT, who
at least to some extent is speaking for ACT. The latter signs his
name as above, so you can distinguish! 

Both Dewar's do their best to get their facts straight and to speak only
THE TRUTH, but feel free to yell at either of them if you disagree :-)

Re: Realtime Ada Conferences

[Larry Howard]

In article <4jdcfd$7gc@news2.delphi.com> tmoran@bix.com writes:
>>Note that these context switch times are for simulated context switching
>>(i.e. threads simulation), rather than for use of operating systems
><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.
><flame off>

Tasking implementors, and sometimes Ada programmers, need to
differentiate between tasking implementation alternatives that
exhibit differing performance properties, including context
switching times.  I took Robert's adjectival use of "simulated"
in the above quote to be no more than a designation of a
particular implementation alternative.

Also, a "context switch" need not refer to a switch to a
_different_ task.  More generally, it refers to the invocation
of the scheduler to select a task to run, which may be the same
task that caused the scheduling event.  Excluding this
possibility means that you would need another label for what is
essentially the same metric.  A better definition of context
switching time is the elapsed time between a scheduling event
and the execution of a particular task.
--
Larry Howard
Software Engineering Institute, Carnegie Mellon University
lph@sei.cmu.edu (NeXT Mail OK)      (412) 268-6397

Re: Realtime Ada Conferences

[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.

Re: Realtime Ada Conferences

[tmoran]

>Note that these context switch times are for simulated context switching
>(i.e. threads simulation), rather than for use of operating systems
<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.
<flame off>

Re: Realtime Ada Conferences

[Kevin D. Heatwole]

In article <dewar.827964202@schonberg>, dewar@cs.nyu.edu (Robert Dewar) wrote:
> A nice capability in the old Alsys technology, which I would expect to
> carry over to the new Thompson technology is a very flexible way of
> spefiying mapping tasks to threads, with 1-1 (use all OS threads)
> and all-1 (simulate all threads) just being two extremes of a very
> flexible way of specifying the mapping. I will let Ed say more
> about this!

Well, I don't know anything about the old Alsys technology, but our
Ada runtime for AIX (part of our PowerAda product) supports such a flexible
scheme.  By default, all tasks are "simulated" but you can bind with
the thread library to execute each task in a separate thread.  You
can also mix the tasks, some "simulated" and some in separate threads.

We continue to support this flexible mapping because:

  1.  Older versions of AIX did not support threads and we wish to be
      compatible with these previous versions of AIX, and

  2.  Not all C library services and AIX system calls are thread-safe.
      AIX usually offers different thread safe routines for doing the
      same services, only with different names and different parameters.
      So, applications that require access to non-thread safe libraries
      can still use Ada tasking (the simulated version) more safely
      (but services like malloc/free are not reentrant in the non-thread
      library so "simulated" tasks still have to serialize access to
      to such services).

  3.  The thread primitives on AIX is much slower than the "simulated"
      primitives in the runtime.  Rendezvous can be an order of magnitude
      slower.  A task context switch from a "simulated" task to another
      "simulated" task takes only slightly more time than a procedure
      call (e.g., setjmp/longjmp times).  But, doing the same thing for
      threaded tasks involves calls to the operating system call.
      For those of you who are interested in such things, one of the
      big reasons that the thread services are slower in the case of
      AIX is that there is no thread-specific memory directly available
      to the thread (all virtual memory is shared by all threads in
      the process).  So, the thread services in the operating system
      often have to figure out what thread is calling them (i.e., 
      pthread_self call) in order to find its thread-specific data.  This
      pthread_self call is implemented as a table lookup using the current
      stack pointer as the key.  Anyway, if IBM could dedicate a register
      or a memory segment for this information, things would be much
      zippier, but they can't change register usage conventions without
      affecting existing binaries.

      Of course, we are only talking about microseconds of time here.  While
      "simulated" task rendezvous may be around 10 mics, the thread task
      rendezvous would be around 100 mics.  In most applications, the
      tasks actually do a lot of other work and the small difference in
      rendezvous times may not be significant in the overall performance
      picture.

So, for the time being, it is important to understand how Ada tasking is
mapped onto your operating system services.  There are distinct advantages
and disadvantages to both mappings, but the serious application that uses
concurrency should consider these aspects during implementation.  

The good news is that the rest of the world is finally recognizing that
concurrency within a single program/process is a good thing to support
and Ada has always made this capability much safer and easier to use.

Kevin Heatwole
OC Systems, Inc.

Re: Realtime Ada Conferences

[Ed Falis]

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
========================================================