On 21/10/2007, Jason Johnson <jason.johnson.081 at gmail.com> wrote:
> On 10/21/07, Peter William Lount <peter at smalltalk.org> wrote:
> > tim Rowledge wrote:
> >
> > Ok, so if you really are talking about a "strict" Erlang style model
> > with ONE Smalltalk process per "image" space (whether or not they are in
> > one protected memory space or many protected memory spaces) where
> > objects are not shared with any other threads except by copying them
> > over the "serialization wire" or by "reference" then I get what you are
> > talking about.
>
> That is a strange way of putting it.  The fact is, Erlang has many
> processes per image.  Many more then you could ever get as real
> processes or native threads (as a test I made a little program that
> spawned 64 *thousand* threads and passed messages between them on my
> laptop).
>
> But with their model, process creation is extremely cheap.  And since
> there is no sharing as far as the language is concerned, there is no
> need for locking to slow everything down.
>
> Smalltalk can do this too. I think it needs a little work still, but
> I'm optimistic about what can be done here.
>
> > However, you'll still end up with concurrency control issues and you've
> > got an object version explosion problem occurring as well. How will you
> > control concurrency problems with your simplified system? Is there a
> > succinct description of the way that Erlang does it? Would that apply to
> > Smalltalk?
>
> Much like how Smalltalk does it, as it turns out.  That is, you don't
> have a version problem so much as you have "old" and "new".  So when
> ready you send the "upgrade" message to  the system and all new calls
> to the main functions of a process will be the new version.  All
> currently running code will access the old code until it's completion,
> and all new code runs in the new space.
>
> > You simplified concurrency system also dramatically alters the Smalltalk
> > paradigm.
>
> The current paradigm is fine-grained locked/shared state.  In my
> opinion and the opinion of many (probably most in fact, outside of the
> Java community) people who are more expert is this area then you or I,
> we *have* to move away from this paradigm.
>
> > Is this the approach that Cincom is using in their Visual Works system?
> > They seem to not be embracing the notion of native threads.
>
> Thank God. :)
>
> > However it's
> > also unlikely that they are embracing the notion of only ONE Smalltalk
> > process per image either.
>
> If I understand you correctly, then I would suggest not to use the
> word "image" as this is confusing.  Another way to put it would be
> "each process has it's own view of the world".  And honestly, what is
> the problem you see with this?
>
> Right now, if you run two separate images with only one thread or
> process, then you have two processes that each have their own set of
> objects in their own space interacting with each other.
>
> Now we add a way for one image to send a message *between* images.
> Perhaps the VM can detect when we are trying to do this, but instead
> of complicating the default Smalltalk message sending subsystem, lets
> make it explicit with some special binary message:
>
> Processes at: 'value computer' ! computeValue.
>
> Now we have the ability to send messages locally within a process, and
> a way of freely sending between processes.  No locking and the
> problems associated with locking.
>
> So, now what is stopping us from moving this separate process *inside
> the same image*?  If you fork a process and he starts making objects,
> no other processes have references to those objects.  No shared state
> issue there.  This part could work right now today with no changes to
> the VM.
>
> The only issue I can think of are globals, the most obvious being
> class side variables.  Note that even classes themselves are not an
> issue because without class side variables, they are effect free
> (well, obviously basicNew would have to be looked at).
>
> But I think this issue is solvable.  The VM could take a "copy on
> write" approach on classes/globals.  That is, a class should be side
> effect free (to itself, i.e. it's the same after every call), so let
> all processes share the memory space where meta-class objects live.
> But as soon as any process tries to modify the class in some way
> (literally, it would be the class modifying itself), he gets his own
> copy.  Processes must not see changes made by other processes, so a
> modification to a global class is a "local only" change.
>
I don't think this have a sense. Classes should be treated as regular
objects (everything is an object - remember?), and due to that fact
you can't make preferences over different kind of objects. Class
objects and instance objects are the same: objects holding a mutable
state.
A method dictionary is a mutable state of class, so changing it should
affect all objects of given class immediately.


> Of course the only big thing left would be; what happens when we add a
> new class.  But Erlang has had success with the old/new space
> approach, and what Smalltalk has now is very similar.
>
>

And btw, i starting doubt about 'no sharing at all' paradigm. Just in
one of the links you given about Erlang, one of the readers commented:
(http://armstrongonsoftware.blogspot.com/2006/08/concurrency-is-easy.html)

---
 Anonymous said...
    One of your premises is obviuosly wrong:

    We don't have shared memory. I have my memory, you have yours, we
have two brains, one each, they are not joined together.

    The premise that the above statement is based on - is that we are
not internally concurrent. The earlier statements in your blog entry
say that we are. The actuality is that all of our individual (i.e.
internal) processes are concurrent and share memory. Even including
our main conscious "thinking" process.

    It is our interaction between individuals that doesn't always
share memeory and even here we do share memory - many examples
(dairies, libaraies, system processes, etc) - in various ways.
---

There an obvious evidence of a system which performs in parallel by
having a single shared state - human brain. Do we experience heavy
'locking' or 'concurrency' problems?
Personally, I'm not :) And if so, then why sharing state should be
considered evil?

Also, in fact, you can't eliminate using shared state at all.
There can be only a ways how to delegate shared state management to
outer context (such as OS, or VM e.t.c).
A 'fine-grained' locking is nothing more than manual controlling of
shared state made by developer.
Try implement Erlang (or any other system which uses parallel
computations and having a shared state) without locks and semaphores.
There are always something needed to manage the locking, even if it
hidden from your eyes. So, tell me, what the difference between
manually controlling it, or 'magically', like Erlang does?

A proposed a message passing between different OS processes(squeak
images) is nothing more than letting OS deal with shared state
problems (locks/queing e.t.c).. naively thinking that we are get rid
of shared state concurrency. Are we really do?

-- 
Best regards,
Igor Stasenko AKA sig.