Re: Unix Multiprogramming with Ada Multitasking

Re: Unix Multiprogramming with Ada Multitasking

[csus.edu!wupost!spool.mu.edu!caen!uflorida!travis!danr]

   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

Re: Unix Multiprogramming with Ada Multitasking

[Robert Ollerton]

In article <6400@travis.csd.harris.com> danr@SSD.CSD.HARRIS.COM (Dan Rittersdor
f) writes:
>
>In article <37464@as0c.sei.cmu.edu> rmo@sei.cmu.edu (Robert Ollerton) writes:
.
. deleted
.
>>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 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.
.
. deleted
.
>>
>>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.

Apologies for not being more specific on my first post.
I do have a special case in mind.  

To minimize cost, military projects often have a requirement to use 
standard military workstations running some version of Unix BSD.  
The application as a whole may use commercially available software 
that does windowing, database management, communication or what have 
you.  In addition, software developed under a previous contract and 
in another language such as C may be part of the application.  There 
is also a requirement to do all future development of the application 
in Ada.  

The Ada multitasking model is out of place in that application for 
the purpose of meeting timeliness needs.  However, Ada is a powerful 
general purpose programming language.  Even in the absence of tasking
Ada can be used in the same way that other languages are used 
to exploit the Unix process model.  There is no conflict between 
Unix and Ada.  Ada fits right in ... unless you use tasking.  

There seems to be a perception that if there is an element of 
concurrency in an application that is implemented (at least in
part) in Ada, tasking must be used.  As far as I know, there is no 
requirement to do this.  The Ada tasking model works just fine in a 
single process model or on a bare target.  Under these circumstances, 
programmers can use Rate Monotonic Analysis (and scheduling) to
be guaranteed that all deadlines will be met.  However, it is 
not possible to achieve this in the application described above.
In that application, an Ada tasking program would be imprisoned in
a Unix process that could be suspended at unpredictable times and 
for indeterminate lengths of time.

Unfortunately, this Ada-Unix question has been confused with the 
issue of tasking performance by people who are not technically 
oriented and have no current knowledge of Ada tasking performance.  
This confusion is exploited by proponents of other languages to make
getting a waiver from using Ada the first order of project business.

Your comments are appreciated.

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

-----------------------------------------------------------------
The opinions expressed here are not those of the U.S. Government.
-----------------------------------------------------------------

Re: Unix Multiprogramming with Ada Multitasking

[Fred J. Roeber]

In article <37528@as0c.sei.cmu.edu> rmo@sei.cmu.edu (Robert Ollerton) writes:
>
>Apologies for not being more specific on my first post.
>I do have a special case in mind.  
>
>To minimize cost, military projects often have a requirement to use 
>standard military workstations running some version of Unix BSD.  
>The application as a whole may use commercially available software 
>that does windowing, database management, communication or what have 
>you.  In addition, software developed under a previous contract and 
>in another language such as C may be part of the application.  There 
>is also a requirement to do all future development of the application 
>in Ada.  
>
>The Ada multitasking model is out of place in that application for 
>the purpose of meeting timeliness needs.  However, Ada is a powerful 
>general purpose programming language.  Even in the absence of tasking
>Ada can be used in the same way that other languages are used 
>to exploit the Unix process model.  There is no conflict between 
>Unix and Ada.  Ada fits right in ... unless you use tasking.  
>
>There seems to be a perception that if there is an element of 
>concurrency in an application that is implemented (at least in
>part) in Ada, tasking must be used.  As far as I know, there is no 
>requirement to do this.  The Ada tasking model works just fine in a 
>single process model or on a bare target.  Under these circumstances, 
>programmers can use Rate Monotonic Analysis (and scheduling) to
>be guaranteed that all deadlines will be met.  However, it is 
>not possible to achieve this in the application described above.
>In that application, an Ada tasking program would be imprisoned in
>a Unix process that could be suspended at unpredictable times and 
>for indeterminate lengths of time.
>
>Unfortunately, this Ada-Unix question has been confused with the 
>issue of tasking performance by people who are not technically 
>oriented and have no current knowledge of Ada tasking performance.  
>This confusion is exploited by proponents of other languages to make
>getting a waiver from using Ada the first order of project business.
>
>Your comments are appreciated.

I agree almost one hundred percent.  We are integrating a large Navy
combat system we developed over the past several years that uses Unix
workstations for the displays and a UYK-43 as the central server.  We used
Ada on the workstations with few problems.  After detailed analysis and
experimentation we also chose not to use Ada tasking for all the reasons
that have been stated in this forum in the past.  While we didn't use
tasking we did use all the other features of Ada.  We feel we have ended
up with a robust and reliable product due to the use of Ada.

Of course there are several important cavaets.  In order to use a UNIX
platform in any application that has real time aspects, you must use a
version of UNIX that supports real time extensions.  We are using a version
of the Silicon Graphics workstations that we militarized along with their
version of UNIX, called IRIX.  IRIX provides an excellent UNIX environment on
which to develop such applications.  Also, the SGI workstations supports/use
the Verdix Ada compiler system which we have found to be the best one for
use in a UNIX environment.

My feeling is that trying to use Ada tasking in an environment that doesn't
adequately support it is a big mistake.  Most implementations of Ada tasking
under UNIX don't provide adequate support.  Once UNIX/POSIX threads become
more readily available and standardized there will probably be more versions
of Ada runtimes that do support adequate tasking performance on a UNIX
platform.  At the recent TRI-Ada, SGI was demonstrating a version of the
Verdix Ada runtime that they developed with Verdix that uses SGI's version
of threads to get parallel execution using UNIX (and spread across
multiple processors).  While we haven't looked at this new product in
detail it certainly does look promising.

    ______________________________________________________________
   |  Fred J Roeber,  Raytheon Submarine Signal Division          |
   |  1847 West Main Road,  Mail Stop 188                         |
   |  Portsmouth, RI  02871-1087  (401) 847-8000 (X4205)          |
   |                                                              |
   |      {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr             |
   |______________________________________________________________|

-----------------------------------------------------------------
The opinions expressed here are mine
-----------------------------------------------------------------


-- 
    ______________________________________________________________
   |  Fred J Roeber,  Raytheon Submarine Signal Division          |
   |  1847 West Main Road,  Mail Stop 188                         |
   |  Portsmouth, RI  02871-1087  (401) 847-8000 (X4205)          |