Hi,

What Ralph and the others have said said is on target in many respects. 
The Erlang and Smalltalk model of messaging have a lot to be desired and 
when combined may provide a powerful and compelling computing platform.

However, having just worked on a very large multi-threaded commercial 
application in live production it is very clear that even single native 
threaded Smalltalk applications have very nasty concurrency problems. 
Our team of seven was able to solve many of the worst of the these 
concurrency problems in a year and a half and improved the reliability 
of this important production application.

It's important that concurrency be taken into account at all levels of 
an application's design, from the lowest levels of the virtual machine 
through the end user experience (which is where concurrency on multiple 
cores can really make a significant paradigm adjusting difference if 
done well).

Of the lessons learned from this complex real world application was that 
almost ALL of the concurrency problems you have with multiple cores 
running N native threads you have with a single core running one native 
thread. The implication of this is that the proposed solutions of 
running multiple images with one native thread each won't really save 
you from concurrency problems, as each image on it's own can have 
serious concurrency issues.

When you have a single native thread running, say, ten to twenty 
Smalltalk green threads (aka Smalltalk processes) the concurrency 
problems can be a real nightmare to contemplate. Comprehension of what 
is happening is exasperated by the limited debugging information 
captured at runtime crash dumps.

Diagnosing the real world concurrency problems in a live production 
application revealed that it's not an easy problem even with one native 
thread running! Additional native threads really wouldn't have changed 
much (assuming that the VM can properly handle GC and other issues as is 
done in Smalltalk MT) with the concurrency problems we were dealing 
with. This includes all the nasty problems with the standard class 
library collection classes.

It is for the above reasons that I support many approaches be 
implemented so that we can find out the best one(s) for various 
application domains.

It's unlikely that there is a one solution fits all needs type of paradigm.

1) With existing Smalltalks (and other languages) it's relatively easy 
to support one image per native "process" (aka task) with their own 
separate memory spaces. This seems to be trivial for squeak. The main 
thing that is needed is an effective and appropriate distributed 
object-messaging system via TCP/IP. This also has the advantage of 
easily distributing the image-nodes across multiple server nodes on a 
network.

I propose that any distributed object messaging system that is developed 
for inter-image communication meet a wide range of criteria and 
application needs before being considered as a part of the upcoming next 
Smalltalk Standard. These criteria would need to be elucidated from the 
literature and the needs of members of the Smalltalk community and their 
clients.

2) It's been mentioned that it would be straightforward to have squeak 
start up multiple copies of the image (or even multiple different 
images) in one process (task) memory space with each image having it's 
own native thread and keeping it's object table and memory separate 
within the larger memory space. This sounds like a very nice approach. 
This is very likely practical for multi-core cpus such as the N-core 
(where N is 2, 4, 8, 64) cpus from AMD, Intel, and Tilera.

3) A single image running on N-cores with M-native threads (M may be 
larger than N) is the full generalization of course.

This may be the best way to take advantage of paradigm shaking chips 
such as the Tile64 processor from Tilera.

However, we may need to rethink the entire architecture of the Smalltalk 
virtual machine notions since the Tile 64 chip has capabilities that 
radically alter the paradigm. Messages between processor nodes take less 
time to pass between nodes then the same amount of data takes to be 
written into memory. Think about that. It offers a new paradigm 
unavailable to other N-Core processors (at this current time).

I believe that we, the Smalltalk community, need to have Smalltalk 
capable of being deployed into the fully generalized scenario running on 
N-cores with M-native threads and with O-images in one memory space 
being able to communicate with P other nodes. It is us that need to do 
the hard work of providing systems that work correctly in the face of 
the multi-core-multi-threaded reality that is now upon us. If we run 
away from the hard work the competitors who tackle it and provide 
workable solutions will prevail.

Food for thought.

All the best,

Peter William Lount
Smalltalk.org Editor
peter at smalltalk.org