Re: Unix Multiprogramming with Ada Multitasking

[csus.edu!wupost!spool.mu.edu!caen!uflorida!travis!danr@ucdavis.ucdavis.ed u (Dan Rittersdorf)]

   Heads-up disclaimer:  I work for Harris Computer Systems Division,
   a manufacturer of real-time shared memory multi-processing 
   Unix-based machines.  I work on the team that developed ARMS,
   the Ada Real-Time Multi-processing System, which provides
   multi-process Ada tasking using the standard Ada language.
   (actually, it's a linker option...)

   Now, on with life...

In article <37464@as0c.sei.cmu.edu> rmo@sei.cmu.edu (Robert Ollerton) writes:
>In a recent meeting I attended, an individual stated that the 
>problem with using Ada multitasking in a Unix multiprogramming 
>application is that there is too much overhead in Ada tasking 
>and it won't be usable until Ada 9X is available.  This was 
>greeted by the most attendees (management types) with nods of 
>assent.  

   Given the Unix Ada implementations of the past, it was true
   that Ada tasking presented a problem, because tasks were simply
   threads of execution within a single unix process, but Unix was
   only able to schedule the entire process.  Task scheduling was 
   handled within an Ada program by the Ada runtime system itself.

   The biggest killer here was that blocking I/O performed by a task 
   blocked the entire application, because the OS could only schedule
   on a per-process basis.  Other tasks within the program remained 
   blocked due to their being part of the same process as the task
   performing the blocking I/O.

   In a multi-programming environment, however, Ada developers 
   could leave tasking by the wayside and design their application
   as a collection of Unix processes.  The same could be done (and
   has, for years) in C and Fortran.  This model overcomes the problem
   of I/O throughput, at the expense of some language features.

   Although, the use of a multi-program design doesn't necessarily 
   preclude the use of Ada tasking within each process...  There isn't
   any inherent overhead in Ada tasking that makes it unusable, 
   as much as there is overhead from the particular implementation
   of Ada tasking (i.e. the single process model).

>
>The sensible thing to do when using Ada in a multiprogramming 
>application is to instantiate O/S processes using Ada subprograms 
>the same as you would with any other high level language.  At
>least one Ada compiler vendor supplies Ada interfaces to Unix
>services which include process creation, interprocess communication,
>signals, and the like.  Lacking vendor-supplied interfaces, the 
>interface pragma can be used to gain access to needed services.
>This requires an understanding of parameter passing mechanisms 
>and the structure of actual parameters.

   Which is what I described above.

   Let me mention again that this multi-program model steps outside
   the universe of the Ada language, requiring knowledge of the OS
   interfaces to provide multi-process capabilities to your application.
   It would be easier (I'd say more portable, but I know how flammable 
   that word is...) to develop the application using standard Ada tasking
   and let the runtime deal with the OS details.  This is what was intended
   from the start, I should think.
   
>
>The problem with using Ada tasking with Unix is that a multitasking 
>Ada program executes within the context of a single Unix process.  

   Unless the vendor of the runtime system provides a mapping of Ada
   tasks to schedulable entities (processes, threads) in the underlying
   OS automatically.  (assuming we *have* an underlying OS here)

   More and more lately, Ada runtimes for Unix and Unix-like systems 
   are being designed to map tasks to OS schedulable entities.  This
   allows standard Ada tasking to be used in the design of Ada 
   programs, which are actually multi-process or multi-thread 
   applications.  The I/O throughput problem goes away, because if
   a task blocks, the OS has the ability to schedule another to run.
   The Developer only has to write standard Ada, reducing the amount of 
   time spent fighting the learning curve.


>Whenever that process is preempted, ALL of the Ada tasks in that 
>program are blocked since the enclosing Unix process is suspended.
>The blocking is unpredictable since Unix is designed to give 
>precedence to "fairness" over "timeliness."

   There are vendors that provide alternate scheduling methods
   for their OS.  Harris provides a "Real-Time" scheduling class in which
   processes have fixed priority.  Others have implemented similar
   features.

   Several vendors have implemented preemption points in their OS
   to provide better interrupt response.  Others, better still, have
   laced the OS with semaphores to allow multi-threading and 
   full preemption of processes in the OS.

   When the Ada runtime makes use of OS schedulable entities to implement
   Ada tasks, the Ada tasking application reaps all the benefits (and
   problems) that the underlying OS has to offer.  Same preemtability,
   same reschedulability, same increase in throughput that a multi-programming
   application enjoys.

>
>I would appreciate comments, pointers, etc.
>

   Broad generalizations about Unix and Ada tasking are no longer valid,
   because people have been saying these things for long enough
   that vendors are doing something about it.  The Ada developers
   and the management they advise need to take the time to evaluate 
   these systems that are addressing the problems.  Ask someone who is
   currently using the new Ada development systems what they think.
   You may be pleasantly surprised.

>Bob Ollerton
>Naval Command Control and Ocean Surveilance Center
>RDT&E division
>rmo@sei.cmu.edu

   I tried to avoid sounding like I think our product is the greatest thing 
   since sliced bread, but if I couldn't help myself, please forgive my
   excitement.

-danr
______________________________________________________________________________
  Dan Rittersdorf                           danr@travis.ssd.csd.harris.com
  Harris Corporation, Computer Systems Division, Fort Lauderdale, FL 33309
______________________________________________________________________________
-Won by One