Time to think about parallel Smalltalk stuff

Alan Grimes alangrimes at starpower.net
Tue Jan 18 18:44:02 UTC 2005


> On the practical side of things, since the Squeak interpreter is 
> basically one big C loop, how would we make use of concurrency?


have multiple seperate loops, one per processor pluss others as needed 
for IO...

> Would we have to fork() the interpreter for each processor, and have 
> the interpreter access block contexts using synchronized accesses?


Fork(), AFAIK, creates two completely independant OS-level hardware VM's 
(not to be confused with smalltalk VMs). They would not be able to 
cooperate after that except through horribly primitive IPC mechanisms.

A problem arising here is that unixoid OSes use the POSIX threading 
library (pthreads), while 'doze has a different (inferior) threading 
model...

> If we could ensure that each block context is only handled by one C 
> thread we could avoid that overhead.  But, to get highly concurrent 
> systems we would need some way to context-switch between Smalltalk 
> executions within a C thread.


Well, I was thinking 1 thread per physical processor (as opposed to 
class Processor). and a multi-threaded scheduler to allaocate Squeak 
tasks to them. (see a very old post I made on this subject.)

On the interpreter level, the current system was not designed to do this 
at all.

When I attempted to paralellize Squeak last spring, my first instinct 
was to divorce class Interpreter from class ObjectMemory.

Right now, there are many variables in structure "foo" that are 
obviously "global" to all threads, and many others that obviously need 
to be unique per thread. My first effort was intended to trim down both 
Interpreter and ObjectMemory as much as possible and then place all 
global information in ObjectMemory and all thread-local information in 
"Interpreter".

One obfuscating factor is that it is not at all obvious from the 
squeak/slang sourcecode what is constant and what is variable. Many of 
the variables you see in the class definitions are compiled as #defines! =P

I started attacking that by taking the class variable typeMask, and 
creating a method: "typeMask:" defined as:

####
typeMask: bits
    ^ bits bitAnd: 3.
####

Which is somewhat cleaner and is unequivocally constant...



More information about the Squeak-dev mailing list