Time to think about parallel Smalltalk stuff
Michael Latta
lattam at mac.com
Tue Jan 18 22:10:10 UTC 2005
The main question is whether to have the threading model inside or
outside the VM. Is the VM responsible for maintaining a pool of
threads that can run on separate CPUs, and the Smalltalk program just
sees Processors for each OS thread? This would probably be the lowest
effort and lowest overhead way to use multiple CPUs. The threads in
the image remain in the image space and are coordinated in their access
to heap etc. The Smalltalk application would also need to use various
control structures to ensure synchronization of accesses. The other
approach is to change the Smalltalk semantic to be more concurrent.
This can be done with proxy objects that defer computations until
needed. A prototype in the Self community saw up to 5 way concurrency
in simple usage with no change in coding.
The question is do programmers want a concurrent language, or a
sequential one? If multi-core computers are where all vendors are
going, we software types should get on board. Rather than treating
concurrency as an exception case to the nice sequential way of viewing
a problem, we should explore turning it on its head. If we embrace
concurrency we get the performance benefits from any concurrent
hardware, we just need to readjust our thinking.
On the practical side of things, since the Squeak interpreter is
basically one big C loop, how would we make use of concurrency? Would
we have to fork() the interpreter for each processor, and have the
interpreter access block contexts using synchronized accesses? 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. This would seem to imply that we will not be able
to guarantee that various segments of the context execute on the same C
thread.
Any other thoughts?
Michael
On Jan 16, 2005, at 10:47 AM, Tim Rowledge wrote:
> http://www.gotw.ca/publications/concurrency-ddj.htm
More information about the Squeak-dev
mailing list
|