>  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