From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=0.0 required=3.0 tests=BAYES_20,MSGID_SHORT autolearn=no autolearn_force=no version=3.4.5-pre1 Date: 10 Jan 92 14:45:41 GMT From: csus.edu!wupost!spool.mu.edu!caen!uflorida!travis!danr@ucdavis.ucdavis.ed u (Dan Rittersdorf) Subject: Re: Unix Multiprogramming with Ada Multitasking Message-ID: <6400@travis.csd.harris.com> List-Id: 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