Path: utzoo!attcan!lsuc!ecicrl!ecijmm!jmm
From: jmm@ecijmm.UUCP (John Macdonald)
Newsgroups: comp.unix.wizards
Subject: Re: What kinds of things would you want in the GNU OS?
Message-ID: <280@ecijmm.UUCP>
Date: 29 May 89 03:12:08 GMT
References: <106326@sun.Eng.Sun.COM> <31756@bu-cs.BU.EDU> <8565@chinet.chi.il.us> <10336@smoke.BRL.MIL>
Reply-To: jmm@ecijmm.UUCP (John Macdonald)
Organization: R. H. Lathwell Associates, Elegant Communications, Inc.
Lines: 54

In article <10336@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>...
>
>The supposed advantage of a thread is that it's cheap to create one,
>even compared with setting up copy-on-write for a fast fork().  The
>obvious disadvantage is that the shared data space requires use of
>concurrency controls among the parallel threads (e.g. monitors).
>Unfortunately, really good concurrency controls don't seem to exist
>at present.  Until someone devises a slick way to do this right in
>high-level languages, I'll continue to prefer separate processes and
>explicit data sharing.
>
>By the way, Burroughs came close with their B5x00 and B6x00 series
>Extended Algol implementations.

A slick way to do this right has been devised more than ten years ago.
This method originated with the (Waterloo) Thoth Operating System [1],
and has since been used and extended in a number of other systems (perhaps
most notably the Stanford V system[2] [and maybe Mach too, but I don't know
about that]).  This method uses small fixed size messages sent between
processes using primitives send, receive, and reply.  The sender blocks
until the receiver accepts the message AND replies to it.  This same mechanism
can be used between any two processes, whether they are "threads in the
same address space" (processes in the same team in Thoth terminology),
or totally different processes.

Processes within a team can use many different ways of organizing their
shared memory, but the message system should be used to co-ordinate transfer
of control of a logical area of memory.  This provides the co-ordinating
capability of a message-based system, without requiring the overhead of
having ALL data interchange be done through messages.  (An additional
feature was a block transfer between processes in different address spaces
between the receive and reply, allowing reasonable data throughput even
when the processes are not on the same team.)

This mechanism allows for a huge amount of non-kernel implementation of
system capabilities, can provide for many capabilities within the
message mechanism (e.g. streams, ioctl, remote systems, file system
switch, spooling servers, it slices, it dices, it makes its own gravy :-)
using a single mechanism in a rather elegant clean fashion.

=== References (sort of) ===

[1] "The Thoth System: Multi-Process Structuring and Portability", by
David R. Cheriton; published by Elsevier/North Holland; ISBN 0-444-00701-6

(There were also a number of papers produced, but I don't have references
for them.)


[2] (Again, I don't have specific references, but there have been many
papers reporting on various aspects of the V system in numerous journals.)
-- 
John Macdonald