OS with threads before 1983
C.W. Holeman
Until the later half of the 1980s, most operating systems
allowed a process to have only one thread of execution.
Which commercially sold operating systems provided multiple threads
prior to 1983?
h_kraus
prior to 1983? <<
IBM's MVS would be one (huge) example. The next year (or late that year),
the MVS/XA architecture was released, and the MVS/ESA release went
out I believe by '89.
BTW, this is still the only *real* mission-critical OS, IMO. Systems like Unix
and NT are for those people that want to take a "huge leap" forward to
"advanced" technology for things like *omigosh*, large memory and files,
multi-threading (called multi-tasking on MVS, since of course any real OS
already has many many programs/sessions active at any time), multiple
processors, real admin/systems mgmt tools, security, fault-tolerant I/O
subsystems, etc, etc.
No, it's not supposed to be flamebait, it just gets wearing sometimes
observing all the hype over the "Unix, no NT, no Unix, NT!, Unix!" wars.
While these new OSs really will be the future and can support many new
applications that MVS can't, they are nowhere even close to being as
powerful or stable for large, mission-critical systems, as many many
projects learned the hard way in '93-94. Witness the huge increase in
staffing and sales (and profits) for IBM and the PCMs.
Still a big NeXTStep/NT/Unix/OS/2 fan (OK, even NetWare for certain
applications),
Harold
hkr...@accessone.com
Lam Dang
: Inside Windows NT by H Custer, page 92:
How about IBM's old standby MVS? Each MVS job is an address space
shared by multiple schedulable tasks, each with its own task control
block describing its context.
--
Lam Dang
dan...@netcom.com
jim frost
I consulted Peterson & Silberschatz' _Operating System Concepts_, 2nd
Ed, 1985. It details no OS's with a recognizable "thread" concept
although it goes into great detail in showing systems which support
processes with multiple execution contexts (most older OS's did this
in order to conserve memory).
However there was much research on concurrent programming systems,
starting with fork/join constructs (M. Conway, circa 1963). Djikstra
was of course highly influential starting in the mid-1960's
(developing the semaphore concept among other things), and Knuth did
his part as well. The early 1970's saw the advent of the critical
section and the monitor, and by the late 1970's there were many
working systems that made use of these constructs.
The 1970's were big on concurrent programming languages, eg Concurrent
Pascal, Modula, CSP, and Pascal Plus. That led us straight into Ada
and other "tasking" languages.
As the concepts were refined and standardized it shouldn't be
surprising that they made their way into the OS as basic services.
Many research OS's of the 1980's started incorporating many of these
concepts, most notably Chorus and Mach, and some commercial systems
(eg OS/2). The late 1980's saw an explosion of such operating
systems.
My references here are sketchy about research from the early 1980's in
this regard (distributed processing was more in vogue I think), but I
suspect that research into realtime operating systems will yield many
more references.
jim frost
ji...@world.std.com
--
http://www.std.com/homepages/jimf
Phil Perucci
And DEC's RSX-11.
--
==============================================================================
Phil Perucci | "All postings are my own opinion - all comments
Systems Integrator | are intended for research/educational purposes"
==============================================================================
M. L.
> Which commercially sold operating systems provided multiple threads
> prior to 1983?
If I remember correctly, DEC's RSX11 had QIO calls with a feature
similar to the later VMS ones. A completion routine could be called.
You could use these to implement a completely seperate thread to do
I/O. You started it by issuing a single QIO call and it would run
to completion on it's own.
I don't know if this qualifies as a "multi-threaded OS" but it
certainly qualifies as pre-1983.
M. L.
> Which commercially sold operating systems provided multiple threads
> prior to 1983?
If I remember correctly, DEC's RSX11 had QIO calls with a feature
similar to the later VMS ones. A completion routine could be called.
You could use these to implement a completely seperate thread to do
I/O. You started it by issuing a single QIO call and it would run
to completion on it's own.
I don't know if this qualifies as a "multi-threaded OS" but it
certainly qualifies as pre-1983.
Mickey Lane
Albert J. Fahey
>
>In article <dangitD2...@netcom.com>, Lam Dang <dan...@netcom.com> wrote:
>>C.W. Holeman (cw...@crash.cts.com) wrote:
>>: Inside Windows NT by H Custer, page 92:
>>: Until the later half of the 1980s, most operating systems
>>: allowed a process to have only one thread of execution.
>>: Which commercially sold operating systems provided multiple threads
>>: prior to 1983?
>>
>>How about IBM's old standby MVS? Each MVS job is an address space
>>shared by multiple schedulable tasks, each with its own task control
>>block describing its context.
anymore ... did I have to allocate the space for a file before I
could write to it ... but anyway ... Did VM did as well (a sort
of left-wing generated IBM operating system).
>
>And DEC's RSX-11.
Really? I can hardly imagine it? Does VMS?
>--
Can anybody confirm these statements? It's not really what I
thought was true from my scant historical view of operating system
development since Multics ... for example.
dave porter
>And DEC's RSX-11.
[as an example of multithreading in an OS]
Nah. An 11M task corresponded to what usually gets called a process these days,
although they were refreshingly lighter in weight.
A task had its own address space.
Within a task, you had one thread of control.
Some might say that the AST mechanism gave you two threads of control, but
I disagree. An AST could interrupt "main task level" code, even if the
main level was stalled, but you couldn't ever stall when running at "AST level"
without stalling the whole task. So you definitely didn't have two
independent threads. One and a half at most; I'd call it one.
ASTs were really just a way of writing event-driven code. Kinda sorta
similar to Windows message processing :-)
I imagine one could have implemented a similar thing on Unix without perturbing
the system too much. Imagine a system call which started something happening and
then returned to the caller. When the thing finally finished (say, when the data
got as far as the disk) the kernel would queue a signal to the orignal process.
Basically, that's what you got with the AST mechanism. Of course, the fundamental
packet-driven nature of the RSX I/O subsystem helped things along.
dave
P.S. If by "RSX-11" you were referring to one of 11A (?), 11B, or 11C, then I claim
no knowledge of those systems. But 11D used the same model as 11M, or rather
11M used the same model as 11D in this respect. 11S and 11M-PLUS can be considered
as 11M variants for this discussion. As can VMS.
Harvey Brydon (918)250-4312
porter) writes:
>In article <3g5edd$3...@access4.digex.net>, pper...@access.digex.net (Phil
Perucci) wrote:
>>And DEC's RSX-11.
>[as an example of multithreading in an OS]
>Nah. An 11M task corresponded to what usually gets called a process these
>days, although they were refreshingly lighter in weight.
>
>A task had its own address space.
>
>Within a task, you had one thread of control.
>
>Some might say that the AST mechanism gave you two threads of control, but
>I disagree. An AST could interrupt "main task level" code, even if the
>main level was stalled, but you couldn't ever stall when running at "AST
>level" without stalling the whole task. So you definitely didn't have two
>independent threads. One and a half at most; I'd call it one.
I'd nominate the Foreground/Background version of RT-11 (ummmmm... what was
the loader called? RKMNFB.SYS? The single job OS loader was xxxxSJ.SYS) I
think it meets the above criteria, and is somewhat aged. I think I used it
circa 1978 (1979 for sure).
_______________________________________________________________
Harvey Brydon | Internet: bry...@tulsa.dowell.slb.com
Schlumberger Dowell | P.O.T.S.: (918)250-4312
I was alive during Woodstock, but I don't remember it - so, I guess
I must have been there...
Giles Morris
>>And DEC's RSX-11.
>
>[as an example of multithreading in an OS]
>
>Nah. An 11M task corresponded to what usually gets called a process these days,
>although they were refreshingly lighter in weight.
I thought that the FORK$ call gave you a new thread (but it's been a long time)
A Home-Brew OS that I worked with in 1974 provided threads. We used it for
control systems.
Giles Morris
h_kraus
CICS was a multi-threaded app that ran in a single address
space (commercial/production release) back in '68/69. It is
still in wide use (even wider with releases for OS/2, AIX, and
AS/400) and for the most part it is backwardly compatible
(the command level) for at least 15-20 years. How many
powerful business-system development tools can make
that claim?
Funny how the systems that process what research groups say are
70-80% of all production data in the world are so forgotten or
unknown to the "new" technology community.
h_kraus
are all subtly different. <<
Hmm, seems like that's what I said<g>.
BTW, I was wondering how you would define the difference between lightweight
and heavyweight threads. Not familiar with the use of this term. My understanding
is that a lightweight *process* is the definition of a "thread". A heavyweight process
can have only one thread.
Of course, threads have their own program counter (PSW), register set (GPRs),
stack space (Save Areas), and share open files and code (using the Attach
macro). MVS threads run as sub-TCBs under a primary TCB, each issuing
their own SVRBs and PRBs.
By this definition there is no doubt that MVS had threads for many many
years before Unix or NT, and that CICS is certainly multi-threaded (it could not
operate properly without it, unless you're confusing it with IPC mechanisms, such
as IMS and the current CICS/ESA use).
Do you know when DG may have had this, like pre 70's? Don't know
anything about DG's history.
Harold
hkr...@accessone.com
John Nagle
UNIVAC EXEC 8, later known as OS/1100, had "threads" from its inception.
EXEC 8 was first demoed on April 4, 1967, and was in production use by 1970.
This OS ran on the UNIVAC 1100 family of machines (now called, I think,
the Unisys "A" series.)
What's now called a "thread" was called an "activity" in EXEC 8.
The system call FORK$ created a new activity in the same address space,
with the initial contents of the registers of the new activity copied
from the old. Any activity could make system calls, and an activity
blocked inside a system call didn't stop other activities. (Many
"thread" implementations don't get this right even today.)
All activities were time-sliced, with a good priority algorithm
(better than UNIX) managing them. Mixes of compute bound and I/O bound
activities worked fine. On multiprocessors, multiple activities of the same
job could be running simultaneously. Synchronization primitives were
provided.
The OS itself used multiple activities internally, forking as
necessary. Activities within the OS kernel could make most system calls,
including I/O.
Even "real time" facilities were provided. A program privileged to
do so could request real-time status, making itself unswappable and
giving its activities priority over non-real time activities (and even
many operating system activities). A program could have mixed real-time
and non-real-time activities, all in the same address space.
The system had good protection against misbehaving programs. The
resources used by an activity came mostly from the job's swappable and
expandable OS table area. Going into an infinite FORK loop just resulted
in hitting the max table size for the job, resulting in job termination.
The system had full memory protection and parameter checking on all system
calls.
All this was way ahead of almost anything else seen in a commercial
OS until the 1980s. But it was real, it worked, and there were huge
data-processing installations using it all through the 1970s.
John Nagle
h_kraus
OS until the 1980s <<
The IBM S/360 architecture supported threads in the mid 60's because
that's what CICS was developed with, and was commercially shipping
in about '68/69. I don't know anything about Univac or Burroughs, but
it wouldn't surprise me if they had similar capabilities back then.
Harold
hkr...@accessone.com
dave porter
>I thought that the FORK$ call gave you a new thread (but it's been a long time)
Well, yes. But a 'fork' was only for use in the exec, and it had a very
limited context -- three registers, one of which was the fork block pointer.
No stack; a fork executed on the common exec stack, but couldn't keep anything
on the stack whilst suspended (the fork function executed a return-to-caller's-caller).
The main function of forks was to provide the mechanism for ISR-level code
to defer some processing to a lower interrupt level.
Rajan Bhardvaj
To the best of my knowledge, Burroughs (Unisys A-Series now) did not
support threads.
However, it did have a fairly clean facilities for IPC and task management:
- frozen libraries which are like DLLs
- port files which are similar to pipes in Unix and even easier to use
- co-routines which allow two processes to co-ordinate execution
between the two processes by handing off control of execution cooperatively
(full pre-emptive multi tasking still occured)
They were symetric multi-processing machines too and its was easy to write
processes which could dynamically spawn worker processes to hand
off tasks etc.
--
Rajan Bhardvaj 202-458-4748 rbha...@worldbank.org