I've not yet seen any serious discussion of the case for your point of view which bridges the gap of complexity in concurrency as automatic memory management magically does. Please illuminate us with specific and complete details of your proposal for such a breakthrough in concurrency complexity.
Peter, Jason is not saying that eliminating shared memory will make concurrent programming as easy as automatic memory management. What he said is that, just like a system that mostly uses automatic memory management might use manual memory management in a few places, so a system that mostly uses message passing for concurrency might use threads and semaphores in a few places.
Making the Squeak VM fully multi-threaded (natively) is going to be a lot of pain and hard to get right. Just ask the Java VM team.
Then either the hard work needs to be done, or the VM needs to be completely rethought.
What Jason said was that, for any VM design, making the VM fully mutl-threaded is hard. It has nothing to do with Squeak or with the Squeak VM.
The pay back of adding this obsolete (except in the lowest level cases) method of dealing with threading just isn't going to be worth the pain to implement it.
What are you going on about? What techniques are you saying are obsolete exactly? How are they obsolete?
He is saying that shared memory parallel programming is obsolete. It doesn't scale. By the time we get to thousands of processors (which will be only a decade) then it won't work at all. Experience shows that it doesn't work very well know even when hardware can support it, because it is just too hard to make correct pograms using that model.
Jason's point, which I agree with, is that programming with threads in shared memory and using semaphores (or monitors, or critical sections) to eliminate interference is a bad idea. Parallel programming with no shared memory, i.e. by having processes only communicate with shared memory, is much easier to program.
-Ralph