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.