Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!gatech!mcnc!rti!xyzzy!wave4!craig
From: craig@wave4.webo.dg.com (Craig Presson)
Newsgroups: comp.unix.wizards
Subject: Re^2: What kinds of things would you want in the GNU OS?
Summary: Life-cycle model of a research topic
Message-ID: <41@wave4.webo.dg.com>
Date: 7 Jun 89 13:29:41 GMT
References: <106326@sun.Eng.Sun.COM> <31756@bu-cs.BU.EDU> <8565@chinet.chi.il.us> <10336@smoke.BRL.MIL> <8591@chinet.chi.il.us>
Reply-To: craig@wave4.dg.com (Craig Presson @ Multitasking General)
Distribution: na
Organization: Data General Corporation, Westborough, MA
Lines: 48

In article <8591@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
>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).
>
>That's what I thought, but I can't see where it would be useful, except
>perhaps to make up for certain OS functions that might be lacking
>like the ability to cheaply determine that no I/O is pending on any
>of several channels so you can continue doing some work without needing
>a new thread.  Wouldn't there be a problem with static data in
>library routines (or anywhere else)?
>
>Les Mikesell
>
You betcha, Les. You definitely have to do something to protect any
static data which may change. In the DG OSes since 1972 or thereabouts,
(RDOS, the AOS family, and the MP/whatevers), there has been a fairly
well-understood mechanism for multithreading a single user program in
a single address space, with user control of task (==thread) creation,
intertask communication, priority, etc. It has been used for many things
over the years, a lot of them real-time flavored, but some not, like
overlapping disk I/O - processing - tape I/O in backup utilities, timers
and alarms in a variety of programs, etc. During that whole evolution,
the #1 easy trap for programmers to fall into was to unknowingly depend on
the value of some unprotected static data, which then changes or becomes
inconsistent. That's why the MACH project, for example, chose to provide
a "C Threads" library with support for well-managed shared variables.

At DG, we just made a religion of re-entrancy, and were helped along
greatly by the sophistication of many application builders. In the
meantime, the state of the art has progressed to the point where the
problem is not to find a mechanism for solving concurrency problems,
but to choose among a profusion of them.

Those who are saddled with language or OS implementations that neglected
to provide for concurrency have my sympathy. I doubt that a smooth way out
is possible; they'll have to hold their breath and upgrade to a modern
OS ...
-- 
"Why am I a look alike a poss of porterpease?"
      -- James Joyce, _Finnegan's Wake_

uunet!wave4.webo.dg.com!craig UUCP                \
craig@wave4.webo.dg.com       CSNET-to-dg/ux-node ->the 3 faces of DG
craig_presson%DGC.ceo.dg.com@relay.cs.net         /
                              CSNET-to-AOS/VS
Craig Presson, Data General, Westborough Mass. dg/ux development