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,7d2c8b4487ef2145
X-Google-Attributes: gid103376,public
From: kilgallen@eisner.decus.org (Larry Kilgallen)
Subject: Re: Ada versus Java - Tasking
Date: 1997/01/19
Message-ID: <1997Jan19.122511.1@eisner>#1/1
X-Deja-AN: 210861631
x-nntp-posting-host: eisner.decus.org
references: <01bc03ee$594dc520$829d6482@joy.ericsson.se>
 <OHK.97Jan19133540@ultra.tfdt-o.nta.no>
x-nntp-posting-user: KILGALLEN
x-trace: 853694721/20050
organization: LJK Software
newsgroups: comp.lang.ada
Date: 1997-01-19T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <OHK.97Jan19133540@ultra.tfdt-o.nta.no>, ohk@ultra.tfdt-o.nta.no (Ole-Hjalmar Kristensen FOU.TD/DELAB) writes:

> calls. My tests have been limited to SunOS and HP-UX, but I suspect
> most other thread implementations will give similar results. A POSIX
> thread will be suspended if the device is not ready, ans as you say,
> other threads may run while the suspended thread is waiting. However,
> my tests indicate that while the (blocking) read/write call is
> executed, the whole OS process is suspended. At least, if you have two
> threads doing IO on separate devices, you will not get any overlap of
> those IO operations. In other words, using a native thread package
> does not automagically transform normal blocking read/write calls into
> asynchronous calls, which I find quite reasonable.
> 
> At best, the native threads give very vague promises about the degree
> of real concurrency, so if I have to choose, I would rather have fast
> task switching and handle any blocking system calls myself.

What guarantees are provided vary not only among operating systems but
also among versions of a given operating system.  Alpha VMS, for instance,
has seen dramatic increases in parallelism up through V7.1 which
just arrived this week.  Conventional wisdom is that this was due
in no small part to competition from Windows NT.  VMS was the
first of the three commercial Alpha operating systems to support
multiprocessors and the last to support scheduling of threads
from a single process simultaneously onto those multiple processors.

Operating system developers have a much better chance to make the
scheduling interact with the hardware properly, so I think the better
choices are:

	1) Rely on OS threading support, and wait for improvements.

	2) Lobby the operating system provider for better support,
	   using all methods available, including examples of other
	   operating systems which do it better, either on the same
	   hardware or some other hardware.

Larry Kilgallen