Path: utzoo!attcan!uunet!aplcen!samsung!think!husc6!m2c!umvlsi!dime!yodaiken
From: yodaiken@freal.cs.umass.edu (victor yodaiken)
Newsgroups: comp.arch
Subject: Re: Personal OS
Message-ID: <15082@dime.cs.umass.edu>
Date: 3 Jun 90 01:30:16 GMT
References: <9437@pt.cs.cmu.edu> <76700219@p.cs.uiuc.edu>
Sender: news@dime.cs.umass.edu
Reply-To: yodaiken@freal.cs.umass.edu (victor yodaiken)
Organization: University of Massachusetts, Amherst
Lines: 22

In article <76700219@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes:
>
>> If you look at the software on the Alto, the system from which much of the
>> one-space mythology is descended, you find that there is no notion of
>> non-interfering parallel processes at all -- all parallelism has to be
>> preplanned -- and the only interprocess-communication method that works
>> between independently-written programs is the file system.
>
>They solved this problem in the Xerox/Pilot OS, see "Experience with
>Processes and Monitors in MESA, CACM, 1978".  Since every module in
>the machine is a reentrant program, and every module may enforce
>mutual exclusion via monitoring, sharing is well-supported.
>

"Solved" is a bit of an overstatement. 
The Mesa compiler will catch many errors that can arise in a shared
workspace environment, but it cannot possibly catch all. It is always
possible to cause a program to make unpredictable memory references.
Architectural support for private workspaces ensures that such errors
will have only local consequences. And
architectural support of private workspaces does not require use of a single
programming language or extensive (slow) run-time support.