🚀 go-pugleaf

In article <C08qF4.Knz@news.iastate.edu>, john@iastate.edu (John Hascall)
writes:
> }>The OS world is moving towards multithreading...
> 
> ...
> Perhaps the research world has been...
> But as far as (popular) commercially available OSes, it would seem not:
> 
>   MS-DOS:  not a chance
>      VMS:  nope

The story for VMS is complicated, and an excellent illustration of why
"yes/no" questions can be misleading.

There are two senses in which VMS has had something very much like threads
from the beginning.  First, a VMS process has embedded within it four streams
of control, one at each access mode (user, supervisor, executive, kernel).
In the modern sense, these are "threads" in the sense that they have separate
sets of registers, separate PC's, and separate stacks, all within one address
space.  However, they are NOT full threads because they from a strict hierar-
chy, and each access mode, in running, blocks the scheduling of the modes
"outside" it.  Also, in practice, inner-mode "threads" don't really suspend
themselves "at" a PC to allow outer-mode threds to run; they just stop.  When
re-activated from outer modes, they generally start from a fixed PC.  How-
ever, this is not a complete description, because of the second feature,
AST's.

AST's (Asynchronous System Traps) are software interrupts.  Each access mode
really splits into two threads, the "normal" level and the "AST" level.
Code running at "normal" level can be interrupted by delivery of an AST,
which then runs at "AST" level, and cannot be further interrupted (except by
code at an inner mode).

It is quite possible - and common, in high-performance, interrupt-driven code
- to have all of the work done within AST routines; the "normal" code just
sleeps.  The result looks very much like code written for a system with
threads.  It's not identical, and it's less general; but it's been there
since the late '70's.

AST's get hardware support on the VAX, in the form of a "pending AST mode"
register and a check by hardware whenever the access mode becomes less
privileged to see if some previously-blocked AST should now be delivered.
On the Alpha, the VMS PALcode services include AST support.

Essentially all system services in VMS that might block have an asynchronous
form.  (The exceptions, some recently "fixed", have to do with things like
opening - not reading, just opening - files.)  The asynchronous forms can
either just set a flag on completion, or deliver an AST (in the form of a call
to a user-specified procedure, passing a user-specified argument).  It is
extremely easy to build threads on top of these services - I did it years
ago, and others have, too - including DEC, for their ADA implementations
among other things.

Unfortunately, the asynchronous options of the underlying services are usually
not accessible from various programming language interfaces - e.g., the C or
FORTRAN I/O libraries have synchronous semantics.

VMS has also had something called PPL (Parallel Programming Library) as an
official part of the OS for about five years.  PPL is a thread-like package
built on top of multiple processes.  The cooperating processes share SOME
of their memory:  They all execute the same code, and they can allocate
memory from a common heap, but they can also have private heaps.  Threads,
processes, or something else?

There's a spec for a supported true threads package for VMS (and OSF); I
don't think it's officially out yet for VMS, but it's been promised.

All of which makes Mr. Hascall's distinction:

>      VMS:  nope
>     UNIX:  not yet

rather curious.

(BTW, the earliest thread package, complete in the modern sense, that I know
of in a commercial operating system was in VAX ELN, a real-time OS for VAXes
that DEC has sold since about 1983.)
							-- Jerry