Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!lll-tis!helios.ee.lbl.gov!nosc!ucsd!ucsdhub!hp-sdd!ncr-sd!ncrlnk!ncrpcd!wright!jsloan@wright.UUCP
From: jsloan@wright.UUCP (John Sloan)
Newsgroups: comp.sys.next
Subject: Re: NeXT & "threads"
Message-ID: <363@thor.wright.EDU>
Date: 27 Oct 88 13:05:44 GMT
References: <10736@reed.UUCP>
Sender: news@wright.EDU
Reply-To: jsloan@wright.UUCP
Lines: 29

Threads, or sometimes "light weight processes", have been around
in various operating systems for a long time. The general accepted
definitions for current technology is that processes run in separate
address spaces, while threads (or LWPs) run in the same address space
as the parent.

There are an awful lot of real-world problems, as Unix programmers well
know, where elegant solutions lend themselves to a multiple process
approach. Unfortunately on most operating systems, multitasking (where
task==process; multiprocessing might be a better term, but usually
means to have multiple CPUs) has too much overhead. Not that that
stops us C programmers, although in fairness Unix perhaps has less
per-process overhead than other operating systems. And you can't beat
the simplicity of the system call to create a new process: a single
parameterless function.

People have been creating light weight process kernels on top of
production operating systems for a long time, or implementing the
same kernels on small non-multitasking systems (like PCs and older
LSI-11s).

Threads are neat. Not necessarily new, although MACH and OS/2 are the
first "commercial" operating systems that I'm aware to feature them,
but still neat.

Copyright 1988 by John Sloan ...!ucsd!ncr-sd!ncrlnk!ncrpcd!wright!jsloan
Wright State University Research Center   jsloan%wright.edu@relay.cs.net
3171 Research Blvd., Kettering, OH 45420       ...!osu-cis!wright!jsloan
Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.