From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,cd2949b907b1f9dd
X-Google-Attributes: gid103376,public
From: kilgallen@eisner.decus.org (Larry Kilgallen)
Subject: Re: mapping of tasking to the OS
Date: 1996/12/06
Message-ID: <1996Dec6.091214.1@eisner>#1/1
X-Deja-AN: 202685026
x-nntp-posting-host: eisner.decus.org
references: <32A7D1E0.3682@sni.de>
x-nntp-posting-user: KILGALLEN
x-trace: 849881539/17521
organization: LJK Software
newsgroups: comp.lang.ada
Date: 1996-12-06T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <32A7D1E0.3682@sni.de>, Michiel Perdeck <perdeck.via@sni.de> writes:
> I am gathering ammunition to propagate the use of Ada in my company 
> (CMG plc) and I have the following question:

> How does the Ada tasking map to a particular operating system? Are there 
> standard ways for this mapping in e.g. Unix (with and without 
> lightweight processes), OS/2, Win95, NT, etc.? And what about some of 
> the well-know C/Unix constructs like fork/exec, does that have an 
> equivalent in Ada? I know that some of my collegues (specifically the 
> Unix affictionado's) will want to be certain how specific multi-tasking 
> constructs are mapped onto the OS! (And don't tell me that one can of 
> course use OS calls in Ada.)

Taking last things first, I doubt that any serious Ada fan would
promote direct OS calls over using the built-in capabilities until
they had receive _lots_ of explanation regarding why the built-in
capabilities were unsuitable for a particular application.  And of
course such an explanation from your OS experts would not be given
(hopefully) until the mapping of the built-in constructs to the
operating system was learned.

Although those who produce Ada compilers generally try to use
mechanisms akin to threading support called by other languages
on a machine, that is a broad generalization and specifics will
depend on the exact compiler and the exact operating system
under consideration.  For an extreme example, DEC Ada on VMS
uses two entirely different mechanisms depending on whether
the machine is Alpha or VAX !

Since you have indicated that your fussiest critics are
likely to be Unix fans (nothing wrong with fussy, Ada folk
revel in fussy), the GNAT implementation of Ada should be
of particular interest for their study, since the source
code is fully available.  I have not read the GNAT code
so I have no direct experience, but it was written by a
bunch of Ada bigots who knew full well that it would be
open to peer review.  These are some of the same folk who
grace the bytes of comp.lang.ada with the common (for c.l.a.)
viewpoint that Ada provides much better opportunity for
writing high-quality code, one of whose qualities is
readability.  So it is possible that in the process of
being fussy about how Ada (the GNAT implementation in
particular) maps to their favorite Unix variant, your
Unix fans will gain some appreciation for the readability
of Ada code.

But for whatever reason, your company may choose to
use a compiler other than GNAT, for which you do not have
access to the source code.  In the Unix environment,
Aonix and OC Systems come to mind.  If your Unix zealots
talk to those vendors _after_ having studied GNAT, they
may be better prepared for asking questions about how
those vendors handle the same issues.

It should be fun.  Like buying a new car/stereo/sailboat,
etc.  If you fully involve the skeptics in _which_ Ada
implementation best suits your needs, you may very well
sail right by the issues of _whether_ Ada comes up to
the quality precedents set by whatever language was used
to implement your Unix :-).

The great thing is that if you use the built-in Ada
constructs for tasking, some Ada compiler which comes
out next year from another vendor which does an even
better job can be adopted with _no_source_changes_.
For that matter, switching between operating systems
(you mentioned OS/2, Win95, NT) involves no source
changes either, so you may end up developing in the
environment with the best debugger and running all
production jobs in the environment with the fastest
CPU.

Larry Kilgallen