Multithreaded Squeak WAS: RE: [ENH] Empty return expression

Stephen Pair spair at advantive.com
Tue Sep 28 19:30:17 UTC 1999



> >And, InstructionStreams are really the fundamental unit of processing and
> >should take much of the responsibility currently held in Process.
> >Especially when considering how one would architect a Squeak that takes
> >advantage of multi-processor CPUs.
>
> Is such work underway?  My intuition tells me that this would be
> related to
> implementation of a Smalltalk which would be multithreaded on a
> single CPU
> (which would be great).

Not that I am aware.  Making Smalltalk multi-threaded is tricky.  Some
Smalltalks have taken the approach of making the "Process" concept in
Smalltalk equate one-for-one with OS threads.  I think that approach is very
bad.  First, it's difficult to implement, and second, it's inefficient
because you have the additional overhead of the OS context switching.

There should never be any more OS threads executing Smalltalk than the
number of microprocessors in the system.  Any more is simply a waste and
will slow down the system (note, having the VM maintain extra threads for
things like disk and socket IO or external calls is a different issue).

The concept of a Process is closely related to the synchronous messaging
that is currently the default in Smalltalk.  If you move to a totally
asynchronous messaging system, the concept of a Process needs to the
re-thought.  Essentially what you have is one process per method context.
Providing an answer from a method (and then sending a message to that
answer) becomes the primary synchronization mechanism.

Moving to a totally asynchronous system on a single processor would likely
be much less efficient than the current synchronous scheme (of course, it
could also be possible to optimize things in such a way that it wouldn't be
much less efficient).  However, if you imagine having 1000 processors on a
single chip at your disposal, perhaps the completely asynchronous messaging
scheme is the only way to go.

So, what's needed is a way to have more control over scheduling the method
contexts on processors directly from Smalltalk.  It might be possible using
OS threads, but it might be a lot easier with more direct control that you
would get by running Squeak without an underlying OS.

Multi-processor chips are not too far off in the future.  It would be really
cool if Squeak were one of the first systems to be able to take advantage of
them.

- Stephen





More information about the Squeak-dev mailing list