Squeak and threads

Stephen Pair spair at advantive.com
Fri Dec 7 22:42:34 UTC 2001


There really is no good reason (that I can think of) for supporting
Smalltalk execution on mutiple OS threads on a single CPU machine.  It
will only degrade your performance and not offer any concurrency
capabilities that Squeak doesn't already have.  Supporting asynchronous
primitives using OS threads is a different matter.

We should however make Squeak capable of utilizing all the CPUs and a
multi-CPU system.  This would involve one OS thread per CPU, which
appears like another Processor in Squeak and scheduling Squeak Processes
on those Processors.  We would need a mechanism for ensuring that the
multiple processes do not step on each other, which would likely involve
a change in the object format...Linda is probably a good conceptual
model for this.  You'd also want to maintain a single-CPU and multi-CPU
version of the VM such that users on single-CPU machines are not
penalized by the additional accounting required in the multi-CPU VM.

- Stephen

> Ruby has its own threads, much like Squeak's (similar to 
> Java's "green 
> threads"). Ruby takes more care to avoid blocking on file 
> I/O, however. 
> Squeak has had async file I/O on some platforms, but I don't 
> think it's 
> universal.
> 
> There are people who would like to see native threads being 
> used (in Ruby as 
> well as in Squeak) but this would be a pain because of the 
> different thread 
> APIs (and Ruby, like Squeak, also runs on platforms that 
> don't necessarily 
> have their own threading model).





More information about the Squeak-dev mailing list