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.

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.