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
|