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=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Path: utzoo!utgpu!watserv1!watmath!att!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!inria!chorus!nocturne!jloup
From: jloup@nocturne.chorus.fr (Jean-Loup Gailly)
Newsgroups: comp.lang.ada
Subject: Re: Ada and OS tasks
Keywords: threads, locking primitives
Message-ID: <6889@chorus.fr>
Date: 23 Nov 90 13:19:52 GMT
References: <1873@sirius.ucs.adelaide.edu.au> <1990Nov20.205819.24040@sctc.com> <13325@encore.Encore.COM>
Sender: jloup@chorus.fr
Reply-To: jloup@nocturne.chorus.fr (Jean-Loup Gailly)
Organization: Chorus systemes, Saint Quentin en Yvelines, France
List-Id: <comp.lang.ada>

In article <13325@encore.Encore.COM>, jcallen@Encore.COM (Jerry Callen) writes:

> I've worked on Ada runtimes that did it both ways. Generally, you have more
> flexibility if Ada tasks use the underlying OS tasks, but you pay a price in
> overhead; how much depends upon the system.

Quite correct. I have also worked (within Alsys) on Ada runtimes that
did it both ways. When Ada tasks are mapped to OS threads, the
rendezvous time is usually dominated by the time spent in the OS, even
when the Ada runtime does its best to minimize the number of system
calls.

> - The OS may not provide much in the way of locking primitives; building your
>   own (with, say test and set and spin locks) may prove problematic. For
>   instance, suppose a task holding a lock is blocked by the OS and another
>   task tries to get the lock? You can burn a lot of CPU in spin locks.
> 
>   This is important because a multi-threaded Ada RTS is going to make
>   heavy use of locking.

Yes, spin locks should not be used, but there are other alternatives. You
can build a very fast locking primitive by making an (expensive)
blocking system call only in the case of contention, that is, when a
test-and-set fails. Variants of this scheme are used in the Alsys Ada
runtimes which map tasks onto OS threads, and in the implementation of
mutexes in the Chorus operating system.

> So how have various Ada implementations done it? Here are a few I am
> familiar with; I'd love to see folks post more.

- Alsys MVS Ada: mapping controlled by pragma and binder options. A variable
  number of MVS tasks can be allocated, each running a variable number of
  Ada tasks. So both extremes are possible (all Ada tasks mapped to one
  MVS task, or one Ada task per MVS task).

- Alsys Ada on LynxOS: the current implementation supports only the one to one
  mapping between Ada tasks and LynxOS threads.

- Alsys Ada on VRTX: also one to one mapping.

- Alsys Unix compilers: the usual "one Unix process for the whole program".
  Predefined IO "does the right thing", that is, one task blocked on IO does
  not block other tasks. However non predefined IO (such as sockets) is
  blocking.

				Jean-loup Gailly
E-mail: jloup@chorus.fr		Chorus systemes, 6 avenue Gustave Eiffel
Fax: +33 (1) 30 57 00 66	78182, St-Quentin-en-Yvelines-Cedex
Tel: +33 (1) 30 64 82 79	France