[comp.lang.smalltalk] parallelism in ST-80

segall@caip.rutgers.edu (Ed Segall) (04/21/89)

Smalltalk has provisions for concurrent execution, but not
parallelism.  In other words, you can simulate parallel operation, but
everything actually happens sequentially.  Semaphores, forked
processes and shared queues are reasonable to work with for simulating
parallelism.  Just remember that things will go quite slowly - you are
simulating the work of many processors!

Caveat: watch out for scheduling.  The default scheduler in ST80 is
not a fair scheduler - you have to make sure your processes stop in
order for others at the same or lower priority to run.  Thus, you have
to resort to some artificial tricks to simulate true concurrency.

There are versions of smalltalk or code in smalltalk that people are
working on which support concurrent programming much more directly.
See the April 89 issue of SIGPLAN notices for the proceedings of the
ACM SIGPLAN workshop on object-based concurrent programming for more
information.


--Ed
-- 


uucp:   {...}!rutgers!caip.rutgers.edu!segall
arpa:   segall@caip.rutgers.edu

johnson@p.cs.uiuc.edu (04/22/89)

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.

srini@mist.CS.ORST.EDU (Srinivas Raghvendra) (04/24/89)

In article <80500052@p.cs.uiuc.edu> johnson@p.cs.uiuc.edu writes:
	>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).  

At Oregon State University, under Prof. Timothy Budd ("Little Smalltalk")
I am trying to implement a parallel version of the Little Smalltalk Interpreter
to run on a multiprocessor machine.

	> . . . .  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.  

Our implementation is on the Sequent Balance. I agree with Prof. Johnson's
idea that Smalltalk is a fine language for parallel programming and I agree
with him that changing the syntax or semantics of the language is really not
necessary. 

The main reason I posted this to the net  is to find out how many other people
are working on similar projects to 'parallelize' Smalltalk without making
significant changes to the syntax. It would be interesting to compare notes,
Also, I am wondering if anybody out there in net land has Smalltalk code that
uses a lot of Process-Semaphore stuff. I would like to try and run such code
on our interpreter and see what kind of a execution time difference we can
acheive by our approach to parallelism.

Disclaimer :
	These are my own opinions and I do not claim to speak for anybody else.

________________________________________________________________________________
--------------------------------------------------------------------------------
Srinivas Raghvendra			Internet : srini@cs.orst.edu
Dept. of Computer Science		Uucp     : ..!hplabs!hp-pcd!orstcs!srini
Oregon State University			Uucp	 : ..!tektronix!orstcs!srini
Corvallis, OR 97331
(503) 754-4471
________________________________________________________________________________
--------------------------------------------------------------------------------
________________________________________________________________________________
--------------------------------------------------------------------------------
Srinivas Raghvendra			Internet : srini@cs.orst.edu
Dept. of Computer Science		Uucp     : ..!hplabs!hp-pcd!orstcs!srini
Oregon State University			Uucp	 : ..!tektronix!orstcs!srini
Corvallis, OR 97331
(503) 754-4471
________________________________________________________________________________

johnson@p.cs.uiuc.edu (04/26/89)

SimTalk, a Smalltalk simulation package developed by people at Tektronix,
is supposed to use a lot of processes and semaphores.  It would make a
neat demonstration of a parallel system.  Although SimTalk is not (yet)
a product, universities can get a license for it for a reasonable fee.
However, it is a fairly big Smalltalk-80 program, and might be a bit
much for a first attempt.