Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

Comp.os.research: Frequently answered questions [1/3: l/m 13 Aug 1996]
Section - [2.2.3] The history of threads

( Part1 - Part2 - Part3 - Single Page )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Business Photos and Profiles ]


Top Document: Comp.os.research: Frequently answered questions [1/3: l/m 13 Aug 1996]
Previous Document: [2.2.2] Characterising implementations of multithreading
Next Document: [3] File systems
See reader questions & answers on this topic! - Help others by sharing your knowledge
From: Recurrent discussions

[93-04-21-13-32.11] [92-01-27-17-05.54] The notion of a thread, as a
sequential flow of control, dates back to 1965, at least, with the
Berkeley Timesharing System.  Only they weren't called threads at that
time, but processes [Dijkstra, 65].  Processes interacted through
shared variables, semaphores, and similar means.  Max Smith did a
prototype threads implementation on Multics around 1970; it used
multiple stacks in a single heavyweight process to support background
compilations.

Perhaps the most important progenitor of threads is the programming
language PL/I, from about the 1965 time frame.  The language as
defined by IBM provided a `CALL XXX (A, B) TASK;' construct, which
forked a thread for XXX.  It is not clear whether any IBM compiler
ever implemented this feature, but it was examined closely while
Multics was being designed; it was decided that the TASK call as
defined didn't map onto processes, since there was no protection
between the threads of control.  So Multics took a different
direction, and the TASK feature was removed from PL/I by IBM in any
case, along with the ABNORMAL attribute and lots of other weird stuff.

Then came Unix, in the early 1970s.  The Unix notion of a `process'
became a sequential thread of control *plus* a virtual address space
(incidentally, the Unix notion of a process derived directly from the
Multics process design [Saltzer, 66]).  So `processes', in the Unix
sense, are quite heavyweight machines.  Since they cannot share memory
(each has its own address space), they interact through pipes,
signals, etc).  Shared memory (also a rather ponderous mechanism) was
added much later.

After some time, Unix users started to miss the old processes that
could share memory.  This led to the `invention' of threads: old-style
processes that shared the address space of a single Unix process.
They also were called `lightweight', by way of contrast with
`heavyweight' Unix processes.  This distinction dates back to the very
late 70s or early 80s, i.e. to the first `microkernels' (Thoth
(precursor of the V-kernel and QNX), Amoeba, Chorus, the
RIG-Accent-Mach family, etc).

On a side note, threads have been in continuous use in
telecommunications applications for quite a long time.

See also:

[Cheriton, 79]
  Cheriton, D. R., `Multi-process structuring and the Thoth operating
    system', Ph.D. Thesis, University of Waterloo, 1979.

[Daley & Dennis, 68]
  Daley, R. C., Dennis, J. B., `Virtual memory, processes, and
    sharing in Multics', Comm, ACM 11, 306-312, May 1968.

[Dennis & van Horn, 66]
  Dennis, J. B., van Horn, E. C., `Programming semantics for
    multiprogrammed computations', MAC-TR-21, 1966.

[Dijkstra, 65]
  Dijkstra, E. W., `Cooperating sequential processes', in `Programming
    Languages', Genuys, F. (ed.), Academic Press, 1965.

[Saltzer, 66]
  Saltzer, J. H., `Traffic control in a multiplexed computer system',
    MAC-TR-30 (Sc.D. Thesis), July, 1966.


User Contributions:

Comment about this article, ask questions, or add new information about this topic:

CAPTCHA




Top Document: Comp.os.research: Frequently answered questions [1/3: l/m 13 Aug 1996]
Previous Document: [2.2.2] Characterising implementations of multithreading
Next Document: [3] File systems

Part1 - Part2 - Part3 - Single Page

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
os-faq@cse.ucsc.edu





Last Update March 27 2014 @ 02:11 PM