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
|