Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uxc!uxc.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!johnson
From: johnson@p.cs.uiuc.edu
Newsgroups: comp.lang.smalltalk
Subject: Re: parallelism in ST-80
Message-ID: <80500052@p.cs.uiuc.edu>
Date: 21 Apr 89 18:41:00 GMT
References: <3736@sdsu.UUCP>
Lines: 28
Nf-ID: #R:sdsu.UUCP:3736:p.cs.uiuc.edu:80500052:000:1598
Nf-From: p.cs.uiuc.edu!johnson    Apr 21 13:41:00 1989


You should distiguish between "Smalltalk--the implementation" and
"Smalltalk--the language".  Smalltalk-80 has only been implemented
to run on a single processor (except for one experimental system
at Stanford, as far as I know).  Thus, although it has Processes
and Semaphores, there is no real parallelism.  However, there is
no reason why there shouldn't be.

Jeong Lim and I have been experimenting with parallel programming
constructs in Smalltalk.  One neat thing to do is to build 
parallel Collection classes, i.e. to have a parDo: operation on
Array that evaluates all the elements in parallel, or maybe to have
a ParArray class that does the same thing for the do: message.  You
can write the code for this using Semaphores and Processes or any
other primitives you might happen to have on hand.

Some people think that Smalltalk has to be changed to permit parallel
programming, i.e. the ConcurrentSmalltalk papers in OOPSLA proceedings.
I disagree.  I think that Smalltalk would be a fine language for
parallel programming on a shared memory machine like a Sequent or an
Encore.  You might want to change the primitives for efficiencies sake,
but that is no big deal.  Distributed memory machines are a little
harder to deal with efficiently, but if you don't care about efficiency
then they aren't a problem, either.  The trick is to make message
forwarding objects that transmit messages from one address space to
another.  Papers on distributed Smalltalk in OOPSLA'87 and encapsulators
in OOPSLA'86 discuss this.  Chapter 15 of Goldberg and Robson discusses
Semaphors and Processes.