mapping of tasking to the OS

mapping of tasking to the OS

[Michiel Perdeck]

I am gathering ammunition to propagate the use of Ada in my company 
(CMG plc) and I have the following question:

Ada supports tasking (multithreading) on the level of the language 
itself, as opposed to most other languages which leave this to OS calls 
who's semantics are not part of the language definition. I think that 
the Ada approach has the great advantage of making it possible to 
formally specify (a program is a formal specification) the concurrency 
aspect of a system. But...

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.)

Regards,
Michiel Perdeck
----------------------
michiel.perdeck@cmg.nl
michiel.perdeck@tip.nl

Re: mapping of tasking to the OS

[Larry Kilgallen]

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

Re: mapping of tasking to the OS

[Robert Dewar]

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).