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: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: mapping of tasking to the OS
Date: 1996/12/07
Message-ID: <dewar.850018640@merv>#1/1
X-Deja-AN: 202947008
references: <32A7D1E0.3682@sni.de> <1996Dec6.091214.1@eisner>
organization: New York University
newsgroups: comp.lang.ada
Date: 1996-12-07T00: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.)


This will vary from compiler to compiler. Generally with GNAT, we map to
operating systems threads where they are available, e.g. on Solaris, to the
underlying Solaris threads. The GNAT runtime tasking (which Larry refers to
as having been written by Ada bigots :-) is in fact as much informed by
the Posix Threads draft 10 standard (i.e. tjhe final Pthreads) as by Ada,
and interfaces pretty directly to Pthreads. There is an abstraction loayer
that also allows interfacing to to variations on this (earlier implementations
of Pthreads, such as DCE threads, and also to OS/2 threads and NT threads).

On some operating systems, e.g. SunOS v4, there is no operating systems
level threads support, and in that case, we use a separate threads package.

We also optionally use this separate threads packages in cases where the
programmer specifies that exact Annex D semantics are required (the Ada
real time annex) and the underlying operating system (e.g. Solaris)
provides subtly incorrect scheduling semantics. [Solaris is almost correct
if you run in super user mode with the real time priorities, but not quite].

Of course, most tasking applications do not use the Dispatching_Policy
pragma, and so the underlying Solaris threads work just fine (and are
the default implementation in the absence of a specific use of this
pragma to specify annex D semantics).