Re: Realtime Ada Conferences

[heatwole@erols.com (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.