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,a5681531ca1cf09e
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Tasking performance between Ada83 and Ada95
Date: 1997/06/23
Message-ID: <dewar.867078847@merv>#1/1
X-Deja-AN: 252083150
References: <1997Jun6.115223.7384@relay.nswc.navy.mil> <dewar.865693453@merv>
  <7h6UFCAdNsmzEwg3@walsh.demon.co.uk> <dewar.865870961@merv>
 <Db0ccBASt4ozEwUo@walsh.demon.co.uk> <dewar.866376446@merv>
 <5oir0v$mgu$1@gonzo.sun3.iaf.nl>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-06-23T00:00:00+00:00
List-Id: <comp.lang.ada>


iGeert Bosch said

<<This scheme could combine the advantages of user-level threads
(fast context switches, fast priority changes and correct Ada
semantics) with those of system-level threads (non-blocking
system-calls and multi-processing).
>>


Quite a reasonable scheme, and in fact alread implemented in some versions
of GNAT. For examle, on the SGI, you have these two levels of support of
threads at the system level, and you can distribute tasks among execution
vehicles (the new SGI terminology for such gizmos) as you wish.

Presumably, though I have not looked in detail, the threads and fibres of
NT give a similar capability.

It is better if the two kinds of threads are implemented at a common level
and not entirely independently, since that places the abstractions at the
right level, and makes sure that such issues as pririty are handled
consistently.