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.5 required=3.0 tests=BAYES_05,FROM_ADDR_WS
	autolearn=no autolearn_force=no version=3.4.5-pre1
Date: 6 Aug 91 14:17:03 GMT
From: mcsun!corton!chorus!nocturne.chorus.fr!jloup@uunet.uu.net  (Jean-Loup Gai
lly)
Subject: Re: Ada and Unix--Blocked Tasks
Message-ID: <11561@chorus.fr>
List-Id: <comp.lang.ada>

Mike Feldman writes in answer to messages by Paul Stachour and Howard
Turner:

| What Paul might be getting at is the notion that an Ada compiler could
| (should) map each Ada task onto an OS-level process. I see no reason in
| principle why this could not be done; indeed, I think there may be vendors
| who are doing it in Unix (can anyone confirm this?). I believe I heard
| that one of the MVS (IBM mainframe) Ada systems can map Ada tasks to MVS
| tasks (can anyone confirm?). In practice, I imagine that vendors are
| keeping an ada program - tasks and all - in one OS-level process for
| efficiency, reasoning that mapping tasks onto processes is overkill.
| 
| This is an area where I'd love to see some material that would let us in
| on some of the "inside" discussions that must have taken place over the
| years. Norm Cohen? Tucker Taft? Bob Eachus? How did the designers 
| imagine the (possible) relationship(s) between tasks and processes?

I was one of the designers of several Alsys Ada compilers. The main
reason we chose to map all tasks in a single Unix process is that Ada
requires all tasks to share memory (unless you put severe restrictions
on the program structure). At the time of the design, it was not
possible to share memory between different Unix processes. On systems
which do allow sharing of memory between OS-level tasks (MVS, LynxOS, VRTX)
the Alsys compilers support a one-to-one mapping between Ada tasks and
OS-level tasks. The MVS compiler even supports a more general M-to-N
model were there can be several Ada tasks per OS-level task and
several OS-tasks per Ada program. The main motivation for this general
model is that tasks switches performed by the Ada runtime without
OS intervention are far more efficient than those requiring system
calls. The user can then tune the program by chosing the best
mapping between Ada tasks and OS tasks. The mapping can be performed
at bind time and does not require recompilation.

There is a little cost for this generality: the M-to-N model is more
complex than the one-to-one model. However the runtime overhead is quite
small and even negligible on systems such as VMS where any system call
costs several thousands instructions.

In the all-to-one model used for Unix, the Ada runtime avoids blocking the
whole process when one Ada tasks makes a blocking IO call, but only
when the predefined IO packages are used. As mentionned by Howard Turner,
the Ada runtime has no control on arbitrary blocking system calls.

To answer your specific comment: there are applications where mapping
Ada tasks onto OS tasks is not overkill but necessary to avoid
blocking the entire Ada program. The M-to-N model lets the user pay
the associated cost only when strictly necessary. On real time systems
such as Chorus where a switch between OS tasks is very efficient, the
simpler one-to-one model is also a sensible solution.

Jean-loup Gailly

Chorus systemes, 6 av G. Eiffel, 78182 St-Quentin-en-Yvelines-Cedex, France
email: jloup@chorus.fr    Tel: +33 (1) 30 64 82 79 Fax: +33 (1) 30 57 00 66