Hi there, I'm following this discussion with great interest,
after introducing myself in what Eralang is by reading http://armstrongonsoftware.blogspot.com/2006/08/concurrency-is-easy.html referenced by Igor, I have a question (that maybe is silly I don't know that's why it's a question after all :)
Some contextualization first:
1. Speculative by analogy:
1.1 Casually about a month ago I've attended a seminar of a neurologist that explained he's research and proposal about a new and more complete theory of dreams. What I've learned there and I'm associating with this regard is the concept of tides, very common for neurologists by the way. They talk about tides of zillion of impulses in the brain cells interconections triggered by senses or even thoughts, emotions, etc.
1.2 the interpretation of (1) Objects as conceptacles in the sense of a receptacle of a concept: "definition of behavior and/or a holder of memory of another/s conceptacle/s" and interpretation of (2) that something trigger a tide which is composed of lots of little impulses.
1.3 this huge quantity of impulses are like well organized little messages that have no problem at all to work concurrently.
1.4 I'm interpreting the normal thousands of processes Erlang manages as analogue (so similar in function) to one of this tides and point why we cannot make tides of Smalltalk message sends in an image?
2. Erlang made it's point in theory about making paralellism really scalable. Then made it's point materializing it into enough succes stories to focus interest of people with pragmatic/con$ervative profiles. The hardware trend indicates this will be of great value.
3. If I understood well, Erlang's main strenght is not that it has functions to do things but that it has a message passing technique really great that was designed to take advantage of parallelism in a simple way efficiently and making processes very cheap (ceaper than the OS ones).
4. If I recall correctly (please correct me if I'm wrong) in "The Computer Revolution hasn't happend yet. Keynote OOPSLA 1997" Alan Kay says that object oriented was not the most happy way of calling OOP becaouse after the initial happines of focusing thought in objects happens to become of a higher priority to think about the process of that objects. This is, not the "body" they have but the "lives" they live with it. So.. he also said that may be process oriented could be a better way to call it todays. Making it's point about the importance of message passing and continues he's talk.
Said that and that I don't have experience with VM internals nor Erlang in an exercise of imagination naively I ask:
The intersticial space of virtual objects, AKA messages sends, can be "Erlanged" by making each message send to be in a "process" (the cheap ones) of it's own like Erlang messages between "process"?
Same in other words:
What consequences will affect us if we make a Squeak to use a VM that to pass messages use processes ala Erlang (that are simple, cheap, efficient and scalable in a world of "cores")?
Can this allow us to assimilate in the Smalltalk's objects paradigm the Erlagn's process paradigm? This is: will this allow us to gain that parallelizing benefits preventing us to change the programing paradigm?
If I understood well this will be (an unknown quantity?) change in the message passing part of the VM and probably has an impact on how todays an image understood what aProcess is to become what it allways should be by giving to processes the importance that they allways deserved and hardware technology wasn't able to deliver (deviating the focus of sofware developers due to sad hardware limitations) to them until todays (in an economy of scale way, AKA cheap). So every message send *is* in one of this different cheap and enormously scalable processes (tens of thousands) that are increasing it's value in the industry todays.
Sorry if I'm being too naif but I had to ask to be able to sleep :)
Sebastian Sastre PD: I've tried to imagine if this saves us from having to make code trhead safe or not. I was unable to refutate this by myself so I also ask kindly that the most experienced and critic minds collaborate on this regard.
-----Mensaje original----- De: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] En nombre de Igor Stasenko Enviado el: Domingo, 21 de Octubre de 2007 09:36 Para: The general-purpose Squeak developers list Asunto: Re: Multy-core CPUs
On 21/10/2007, Jason Johnson jason.johnson.081@gmail.com wrote:
On 10/21/07, Peter William Lount peter@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-i
s-easy.html)
Anonymous said... One of your premises is obviuosly wrong:
We don't have shared memory. I have my memory, you haveyours, we have two brains, one each, they are not joined together.
The premise that the above statement is based on - isthat 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'talways 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.