Runar Jordahl read the paper I pointed to this morning, and drew the same conclusion as the author of that paper did:

As discussed here, native threads are based on shared state. In the discussion, threads are (correctly) defined as “shared-state concurrency”, while processes are “threads without shared state”. The problem with threads is that the shared memory is modified non-deterministic. Since threads run in parallel and each thread might be scheduled differently per execution, every execution of the program tends to produce different intermediate results. This means the danger of deadlock or other side effects are not easily detected through testing. Reproducing a problem can be impossible. Contrast this with the green thread model used in most Smalltalk images: With green threads the program runs deterministic.

Running multiple Smalltalk images basically means running multiple processes. The processes will not share data directly in memory. (VisualWorks images can share static data, but that is another story. Of course, this cannot lead to the discussed problems.) An implementation using a divide and conquer algorithm with multiple images can also easily be designed to run deterministic. Testing, debugging, and understanding such a setup will be a lot easier than a (native) thread implementation.

I've been explaining this to people who want multi-threaded Cincom Smalltalk VM's for a long, long time now - the end result of that wish would be a less stable VM that had subtle bugs. A better answer: use multiple images and interprocess communication (such as Opentalk) to get the job done.

Technorati Tags: threads, processes, smalltalk