<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Ralph, <br>
<br>
It's good to converse again with you. It's been many years.<br>
<br>
<blockquote
cite="mid:e5fa86ac0710202041y6b96da9qf7fab5c5241c36e0@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap=""> 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.
</pre>
</blockquote>
<pre wrap=""><!---->
Peter, Jason is not saying that eliminating shared memory will make
concurrent programming as easy as automatic memory management. </pre>
</blockquote>
<br>
That's good for that makes no sense given real world experience with
systems that don't use shared memory as a basis for their currency
control.<br>
<br>
<br>
<blockquote
cite="mid:e5fa86ac0710202041y6b96da9qf7fab5c5241c36e0@mail.gmail.com"
type="cite">
<pre wrap=""> 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.
</pre>
</blockquote>
<br>
Ok, that sounds nice and rosey but so far. Can someone please explain
in full detail and completely how it would actually work? Thanks.<br>
<br>
<br>
<blockquote
cite="mid:e5fa86ac0710202041y6b96da9qf7fab5c5241c36e0@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
<br>
Yes, I'm clear about that. That's why I said that the hard work needs
to be done by those of us who are knowledgeable and more experienced
than the typical programmer using Smalltalk. We are supposed to be
systems people aren't we? We are supposed to do the hard work so that
others have an easier time aren't we? Of course if we can avoid the
hard work then I'm all for it. However when it comes to concurrency
control and program consistency it just isn't possible to avoid the
hard work.<br>
<br>
<blockquote
cite="mid:e5fa86ac0710202041y6b96da9qf7fab5c5241c36e0@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap=""> 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?
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
<br>
So, two processes that share a chunk of RAM memory across their
protected memory spaces is obsolete in your view? <br>
<br>
What about two or N light weight threads (aka Smalltalk processes) in
one memory space sharing objects in that single memory space? Is that
obsolete as well? <br>
<br>
<br>
<blockquote
cite="mid:e5fa86ac0710202041y6b96da9qf7fab5c5241c36e0@mail.gmail.com"
type="cite">
<pre wrap="">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. </pre>
</blockquote>
<br>
Ok. I get that it's complex and that there are scaling issues with some
of the techniques when N-core is very large. I don't see how it's a bad
idea though - I don't see how it's any worse than the alternative
that's being suggested.<br>
<br>
<blockquote
cite="mid:e5fa86ac0710202041y6b96da9qf7fab5c5241c36e0@mail.gmail.com"
type="cite">
<pre wrap="">Parallel programming with no
shared memory, i.e. by having processes only communicate with shared
memory, is much easier to program.
</pre>
</blockquote>
<br>
So you mean one thread per protected memory space? No light weight
threads (since they are using shared memory by definition)? Not more
than one Smalltalk process per protected memory space? Just one thread
of execution for each operating system process/task? So if I want one
hundred Smalltalk processes running in my application I will need one
hundred operating system processes? <br>
<br>
All objects are to be copied across the memory space boundaries via
serialized objects or via references (for copying later or for return
messages back to the originating node later)?<br>
<br>
No "active" object running in it's own operating system process can
respond to more than one inbound message at once? Since it only has one
thread/Smalltalk process to avoid shared memory it must complete all
the work that the current message send caused. What about deadlock
avoidance in your model?<br>
<br>
Maybe I'm misunderstanding your definitions but it seems to me that
that is what is implied by what you are saying.<br>
<br>
To ensure clarity on this complex topic please provide definitions and
full explanations with examples. Please be very detailed. Thanks very
much.<br>
<br>
All the best,<br>
<br>
Peter<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>