Multy-core CPUs

Hi Ralph,

Continued.

>> Parallel programming with no
>> shared memory, i.e. by having processes only communicate with shared
>> memory, is much easier to program.
>>    

Another way to express what I'm saying is the following. You can run
multiple processes in either separate or one memory space. When running
in one memory space the following applies.

Sure you could have N threads - native or green - each running ONE
(Squeak) Smalltalk process running in one protected memory space as long
as NONE of these threads share ANY memory between them. That means no
objects being shared. That means each Smalltalk process is really it's
own image running independently with only one user level Smalltalk
process. Any communication between them with objects is serialized and
transmitted in some manner that - oh dear - avoids using shared memory
or a shared communications "buffer" between two or more threads. This is
done even though sending messages via shared memory buffers in one
protected memory space is very efficient or sending messages via a
shared memory space when more than one protected memory space is in use
is also very efficient.

It seems to me that as soon as you have more than one Smalltalk process
running in a Smalltalk image you will have concurrency control issues -
unless the forked off threads are trivial in nature. This fact is the
reason that I don't share your optimism about your solution - for if you
have more than one thread in accessing the same memory space -
regardless if they are in the same protected memory space or across
operating system processes - you've got the concurrency complexity and
program data consistency issues occurring. How do you avoid that?

Please educate me so that I fully understand your proposed solution.
Thank you.

All the best,

peter

I'm sure I'm going to regret saying anything in this thread but what  
the hell...
>
> Sure you could have N threads - native or green - each running ONE  
> (Squeak) Smalltalk process running in one protected memory space as  
> long as NONE of these threads share ANY memory between them.
I don't think that was actually specified but yes that would be one  
way of doing it.


> That means no objects being shared.

No it doesn't. Objects can be shared via communication; that's what  
messages are  for. It only happens that the Smalltalk systems we're  
mostly used to share by sharing memory.

> That means each Smalltalk process is really it's own image running  
> independently with only one user level Smalltalk process.
Works for me. Like an ecology of cells. Now where did I hear that  
analogy before? Oh, yes, I think it might have been either Alan Kay's  
doctoral thesis or an early talk on the idea of objects.


> Any communication between them with objects is serialized and  
> transmitted in some manner that - oh dear - avoids using shared  
> memory or a shared communications "buffer" between two or more  
> threads.

Transputer.

> This is done even though sending messages via shared memory buffers  
> in one protected memory space is very efficient or sending messages  
> via a shared memory space when more than one protected memory space  
> is in use is also very efficient.
Only applies in the limited sphere of the typical single processor  
systems we have got used to over the last few years. And for the  
purposes of any discussion about real parallelism, current 2/4/8 core  
systems are really a poor quality patch on the single cpu idea.

A key idea that people are going to have to get used to is, oddly  
enough, just like the one they had to get used to in order to accept  
late binding and dynamic languages. That is, to paraphrase a old  
quotation from Dan Ingalls (I'm pretty certain)
"we've got past the stage of worrying about the number of  
computational cycles. we need to start worrying about the quality"
Nominal inefficiency in having message passing across processes done  
by something 'slower' than shared memory may be a key to allowing  
massively spread computation. Trading the 'efficiency' of hand coded  
assembler for higher level languages made it more practical to build  
bigger programs that could do more. Trading the 'efficiency' of C for  
a decent late bound language allows more conceptually complex  
problems to be tackled. Trading the 'efficiency' of shared memory as  
a medium for sharing information with some other transmission method  
may be the lever to unlock really complex systems.

I think it's time people read up a bit on some computational history.  
Quite a bit of this stuff was worked on in the old days before the  
x86 started to dominate the world with a saurian single-core  
brutishness. Learn about Occam for example.

And Peter, before I "explain in full detail and completely how it  
would actually work" how about you explain in full detail and  
completely how you're going to fund my research? ;-)


tim
PS another 'randomly chosen' sigline that manages to be eerily  
appropriate
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Try not to let implementation details sneak into design documents.

Peter William Lount wrote:
> Ok, that sounds nice and rosey but so far. Can someone please explain in
> full detail and completely how it would actually work? Thanks.

http://www.erights.org

Cheers,
   - Andreas

tim Rowledge wrote:
> I'm sure I'm going to regret saying anything in this thread but what
> the hell...

;--)


>>
>> Sure you could have N threads - native or green - each running ONE
>> (Squeak) Smalltalk process running in one protected memory space as
>> long as NONE of these threads share ANY memory between them.
> I don't think that was actually specified but yes that would be one
> way of doing it.

That is essentially the Erlang way, isn't it?

>> That means no objects being shared.
>
> No it doesn't. Objects can be shared via communication; that's what
> messages are  for. It only happens that the Smalltalk systems we're
> mostly used to share by sharing memory.

I meant what you said. ;--)


>> That means each Smalltalk process is really it's own image running
>> independently with only one user level Smalltalk process.
> Works for me. Like an ecology of cells. Now where did I hear that
> analogy before? Oh, yes, I think it might have been either Alan Kay's
> doctoral thesis or an early talk on the idea of objects.

It would be good to turn up a reference to that. Alan? Is your doctoral
thesis online? If not could it be?


>> Any communication between them with objects is serialized and
>> transmitted in some manner that - oh dear - avoids using shared
>> memory or a shared communications "buffer" between two or more threads.
>
> Transputer.

Yeah, those were sweet. The Tile64 seems similar in many ways.


>> This is done even though sending messages via shared memory buffers
>> in one protected memory space is very efficient or sending messages
>> via a shared memory space when more than one protected memory space
>> is in use is also very efficient.
> Only applies in the limited sphere of the typical single processor
> systems we have got used to over the last few years. And for the
> purposes of any discussion about real parallelism, current 2/4/8 core
> systems are really a poor quality patch on the single cpu idea.

Well not really and regardless of that using a shared memory buffer is
an efficient manner of transport for a serialized object message (with
or without complete objects or just references or a mix of the two) in
the case of a system with N-cores and shared memory between protected
memory spaces. When the images are in separate server nodes then using
TCP/IP is needed. Using TCP/IP locally on one server box may or may not
make sense and would likely be slower than a direct shared memory buffer
although it's possible that the OS might optimize for that case.

I'm all for wisdom in computing, if I wasn't I'd not be using Smalltalk!


> I think it's time people read up a bit on some computational history.
> Quite a bit of this stuff was worked on in the old days before the x86
> started to dominate the world with a saurian single-core brutishness.
> Learn about Occam for example.
>
> And Peter, before I "explain in full detail and completely how it
> would actually work" how about you explain in full detail and
> completely how you're going to fund my research? ;-)

;--) That was my next line for you!!! ;--)

Seriously, if I could I would.


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.

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?

If on the other hand, you are allowing more than one process per "image"
then you don't gain anything at all since anytime you have more than one
thread on a memory space you have all the concurrency problems that
shared memory between operating system process give you.

You simplified concurrency system also dramatically alters the Smalltalk
paradigm.

What have I missed or left out from what is being proposed or worked on?

Is this the approach that Cincom is using in their Visual Works system?
They seem to not be embracing the notion of native threads. However it's
also unlikely that they are embracing the notion of only ONE Smalltalk
process per image either. At least in the sense of preventing a user
from forking off additional Smalltalk processes in the same memory
space. To truly support the above simplified model "forking" of blocks
of code will need to slice off a copy of the entire image (some one did
that for Squeak a while back). Then you have all the problems with
object versions. Sigh.

One shoe doesn't fit all solutions.

All the best,

Peter

On 10/21/07, Peter William Lount <[hidden email]> wrote:
>
>  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.

Here is a reference to my break down again:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-February/114181.html.

I'm not saying *actor style concurrency is the same complexity as
garbage collection* nor *manual memory management is as complex as
fine-grained locking*.

It is an analogy:  Fine-grained locking is to Message passing what
manual memory is to generational garbage collection.

>  Then either the hard work needs to be done, or the VM needs to be
> completely rethought.

I don't think you realize the level of work required here.  Look at
the work of David Griswold and Strongalk.  I wanted to provide a
reference, but I believe he states his position most clearly on one of
the "Industry misinterpretations" podcasts.  What he said was
something to the effect of "we did this in Java with a large group of
people and much money focused on it, and it took a long time.  I don't
think this is going to be possible in the free software world with our
limited time".  Something like that, and I agree.  Though I take it
one step further and say it's not needed.

>  What are you going on about? What techniques are you saying are obsolete
> exactly? How are they obsolete?

Here again I mean obsolete in the way that using manual memory
management for everything is obsolete.  Of course one must use manual
memory management at the very lowest levels.  And likely (dependent on
the OS or CPU architecture) one will need fine-grained locking at the
very lowest levels.  But no one else should.

In this paper a team writes some software in a locking style, and
again with STM and no explicit locking.  You go go straight to chapter
4 for the graphs, and keep in mind; the STM version behaves properly
in the face of exceptions while the locking version does not.  I also
don't recall if they mentioned how long each implementation took, but
certainly a locking version is harder to get right.

http://www.haskell.org/~simonmar/papers/lockfreedatastructures.pdf

>  Why? 64 processors on a single chip - with 128 coming next year and 1024
> planned - that's why.

Ok, that explains why we need parallelization, but it doesn't explain
why we need fine-grained locking.

>  You've missed the point. Even the simplest of concurrency methods proposed
> so far by people in the Squeak thread lead to the most complex concurrency
> control error scenarios. That's one of the points. Another is that the
> simplest of concurrency models can't handle all the scenarios.

Where do you come up with this information?  From one application you
worked on that was threaded?  The Erlang people have been working on
this stuff for the bulk (if not the entirety) of their careers.
Forgive me if I give more weight to their research then your opinion:

http://armstrongonsoftware.blogspot.com/2006/08/concurrency-is-easy.html
(note how close this is to the message passing we talk about in
Smalltalk.  more on this below)
http://armstrongonsoftware.blogspot.com/2006/09/why-i-dont-like-shared-memory.html

http://ll2.ai.mit.edu/talks/armstrong.pdf
http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf
http://pragmaticprogrammer.com/articles/erlang.html

And I really don't understand why you think one thing can't be done in
the other.  Anything you can do with fine-grained locking you can do
with message passing (at least from an application level, though
depending on the CPU it might be equivalent at all levels).

http://armstrongonsoftware.blogspot.com/2006/09/pure-and-simple-transaction-memories.html

>  As asked above please describe in detail and completely the proposed
> "simple" approach to concurrency that is being proposed. Links to
> appropriate descriptions if it exist would also be fine (unless it contains
> too much extraneous text).

I think the texts above should provide pretty good detail.  The one
wrinkle is that in Smalltalk we do in fact have shared state, so
something *would* have to change, as discussed in the thread I linked
to near the top of this message.

But I still think it's doable.  Objects themselves are not normally a
problem, it's class side variables that would cause the biggest
problem in our current system.  I have some ideas on how to deal with
this, but it will be a while before I can look at it.

>  The problem with concurrency is that it's much more complex by orders of
> magnitude than garbage collection. Much more complex a beast, so much more
> so that the comparison breaks down.

I don't believe it does.  One *does* have to write programs
differently in an Erlang style message passing world (in a more OO
way!), but there is no functionality you can achieve with
fine-grained/shared state that you can't with message passing.

>  Thank you for calling it "odd". That's what happens when you think
> different, at first people think it odd. I often encourage people to think
> different as Apple does in their marketing of a few years ago.

No, I said it was odd because you put Java and Erlang in the same boat
despite the fact that Java is completely in bed with the old
fine-grained/shared state and Erlang is on the exact opposite side of
the board.  And then you said Smalltalk would somehow lose market
share to them because of this...

>  How is that?

Show me another system achieving the same level of parallelism, fault
tolerance, lines of code and *9 9's* (!!!) of reliability.

http://www.cincomsmalltalk.com/userblogs/ralph/blogView?showComments=true&entry=3364027251

>  Yes, but Erlang is a purely function non-object-oriented
> non-keyword-message passing language.

Are you saying that someone who disagrees with how you see the world
is wrong/lesser?

Anyway, this is one way to look at it.  Another way to look at it is
that Erlang is not so far from the vision Alan Kay talked about.
Think about it; a process is an encapsulated entity which you can only
interact with via messages.  This is OO at a whole new level.

>  While it has a form of message passing it's not the same as Smalltalk's.
> It's simply passing parameters to functions that run in separate green or
> native threads.

Or on completely different machines.  But the calls look the same.
Encapsulation is a nice thing, eh? :)

>  Yes it is impressive what they have accomplished, but it isn't the be all
> and end all.

I didn't say it was.  If I thought it was I would be there, instead of
here planning to see how far Smalltalk can go with this.

>  I simply think that having all the tools at our disposal is important to
> maintaining and growing market share.

That's not a sure thing.  Ask C++.  Sometimes finding a simple idea
that's equivalent (e.g. Smalltalk and for that matter even Java) beats
"having all the tools at our disposal" (e.g. C++).

>  "Simpler to implement" concurrency leads to just as difficult to manage
> software systems as more complex well thought out concurrency. In fact, I
> think, that making it simplistic will lead many programmers to implement
> software that is impossible to debug without enormous efforts. The problem
> is that even the simplest concurrency leads to the nastiest and most complex
> bugs in software.

This is simply not true in the case of message passing.  Message
passing is to concurrency what OO is to programming.  That is, in
shared-state/fine-grained you drown in complexity because every new
piece of code has to be considered against all the existing code to
see if new deadlocks/et al. are possible.

In message passing you have a process that does X.  You want to add
something new to the system that uses this
service/process/object/whatever you want to call it?  Just do it.  The
only question is: should we spawn another X to handle the extra load.
But no possible solution can relieve you of the responsibility to
think.

>  I don't see how you can have a simple concurrency threading model solve the
> problems of when and how to use concurrency properly to avoid the many
> pitfalls of threading. If you can see that please illuminate it for the rest
> of us.

Well, let's see.  The pitfalls of fine-grained locking revolve around
locking.  Locking is needed to protect the consistency of shared
state.  If you get rid of shared state, you get rid of locking and you
get rid of the problems associated with it.

It is still possible to make software in such a way that it deadlocks,
priority starves and so on, but not nearly as easy as in the
shared-state/fine-grained locking model, and much easier to correct.

>  Do you mean Tim Sweeney the game developer?
> http://en.wikipedia.org/wiki/Tim_Sweeney_(game_developer)

Yes.

>  Alright even though I don't know Tim I'll take the bait and see where it
> goes, Tim Sweeney (or Sweeny) what do you think? (If someone who knows him
> would be kind enough to pass this thread on to him or post his thoughts on
> this topic that would be great - thanks).

Here is what I was talking about:
http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf

I don't agree with his conclusions, but given that his domain is high
performance games, he is worried about speed and thinks message
passing can't be as fast.

>  Threading including native threading on one core or N cores (where N can be
> large) under existing operating systems is very important to the future of
> Smalltalk.

Unless of course the idea of a native thread is itself wrong.  The
idea is just that a process has one or more "threads of execution"
(basically, just an IC and a stack), but is this good encapsulation?
After decades of race conditions, I would say no, it was in fact a
premature optimization.

This may look good on current OS'es and hardware, but instead of
working from there, lets imagine how things would look if the most
pure design was also the fastest/most efficient.  Would you use the
native thread model?  I wouldn't.  I would make messages the key
concept, and make them the fastest method of interprocess
communication.

>  For clarity purposes, please define in detail what you mean when you use
> the phrase "fine-grained threading model" so that we can make sure that we
> are on  the same page.

I think it's laid out pretty clearly in my post to the other thread
(referenced above).  But here is the reference card version:

fine-grained locking/shared state:  State is shared among threads of
execution.  Access is handled by synchronization mechanism such as
Mutexes, Symephores and so on.

STM:  Think relational database transactions, including rollbacks and so on.

Message passing:  Erlang is the most successful version of this I know
of, but certainly not the only one.  Lisp had this option for a long
time, as did many others (Smalltalk as well I'm sure).

>  You seem to think that there is some magical breakthrough in the world of
> concurrency that is on par with the magic of automatic garbage collection.
> I'd sure love to know what that is and how it avoids the pitfalls with even
> simple concurrency models and issues that occur in real world projects. If
> you could, please describe in full detail and completely with real world
> examples. Thanks very much.

Let me know if the above wasn't enough detail.  But just to reiterate:
 most concurrency problems we have come from trying to share memory.
Get rid of that and many of these issues literally disappear.  The
rest become a design concern instead of an implementation detail, and
surely you would agree that this is how it should be.

On 10/21/07, Peter William Lount <[hidden email]> 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.

On 21/10/2007, Jason Johnson <[hidden email]> wrote: 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.

On 10/21/07, Igor Stasenko <[hidden email]> wrote:
>
> 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.

Ah, but they are the same, I'm not making a difference, I'm making an
optimization and not getting caught. ;)

> Class
> objects and instance objects are the same: objects holding a mutable
> state.

Fine, you can have mutable state.  But only within your own process.
If you change it no other process will see it.

> A method dictionary is a mutable state of class, so changing it should
> affect all objects of given class immediately.

This is a special case in my envisioned system, just as it's a special case now.

> 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)

Ok, so someone presented a counter-point about a meaningless analogy,
and that disproves the power of message passing?

You can doubt it if you want.  You can work incredibly hard for the
next 5, 10 years or however long it takes and add native thread shared
state concurrency to Squeak.  But Erlang will continue to gain market
share.  Dinosaurs like Java, with their old shared-state model will
get less and less relevant as concurrent software gets the complexity
explosion that web software is going through now.  And if your fast
you will make it just in time to charge into the party as the last
light goes out.

> 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?

For the same reason manual memory management is in most cases:  It's
too hard to get right, it's too hard to reason about, it's impossible
to compose with other software made independently.

Now of course we can get back into the watershed of beating ourselves
for being "bad programmers" but after so many failed projects, and
success itself meaning simply having a small enough critical bugs to
be usable, maybe we should admit we're trying to put the shoe on
backwards.

> Also, in fact, you can't eliminate using shared state at all.

I don't think that's been proven at all.  In fact there have been
OS'es to do exactly that.

> There can be only a ways how to delegate shared state management to
> outer context (such as OS, or VM e.t.c).

That it doesn't have to be shared state.  Does Linux have shared
state?  I don't recall ever having to lock a mutex before reading a
disk, or allocating memory or anything.  Of course Linux does have
shared resources internally, but if you broke it up into smaller
"Kernels" that each had a the same interface between each other then
perhaps this could be eliminated.

> A 'fine-grained' locking is nothing more than manual controlling of
> shared state made by developer.

Exactly, and manual memory management is nothing more then manual
controlling of memory made by the developer.

> Try implement Erlang (or any other system which uses parallel
> computations and having a shared state) without locks and semaphores.

That depends on the OS and CPU, not the problem domain.

> So, tell me, what the difference between
> manually controlling it, or 'magically', like Erlang does?

Seriously?  Well lets see:  (1) lines of code needed to accomplish a
given task, (2) literally man *years* of work time, (3) stability of
finished product (or perhaps you know of a Java/C++/whatever system
that is in heavy use and achieves 9 9's of reliability?), (4)
difficulty of solving bug that do appear due to concurrency, (5) the
ability to solve concurrency issues at *design time* instead of
*implementation time* (probably the most important of all of them),
....

> 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?

Please reread what you wrote here because.... What you basically said
is "doing X is nothing more then letting the OS and/or system deal
with the complexity for us and naively thinking it just goes away".
Is this not the exact reason we are using Smalltalk instead of C++, C
or assembler?

On 21/10/2007, Jason Johnson <[hidden email]> wrote: Hehe, then all we need is to implement ST with Erlang and we are fine. Yes? :)
If you noticed, i'm not arguing about is it possible to make ST VM
ready for multi-core.
I'm really pointing on, how efficient it can be (depends on proposed
solutions) and what we can do to make good VM competing by speed with
other language platforms.
If we not taking speed into account, then there's nothing to talk about.

And don't tell me that trying to make ST to run as fast as can is
pointless...  Such thoughts are only for people, who taking a car and
drive to wall-mart to buy a glass of water, located in 20 feets from
their house.

For same reasons as you don't want use C++/C/assembler for your
projects i don't want them too. But at same time, i don't like being
sitting and waiting, while other parts of system (OS/Hardware) become
so advanced to make my code run smoothly. If i don't like how it runs,
i trying to fix that instead of waiting until someone else will fix
it.

As side note, i don't want to make one ST Process === single native
thread. Such solution is really 'obsolete' and lead to nowhere. I'm
talking about VM which conserves all CPU(s) power while managing
execution/GC seamlessly to language. The in-language Processes and
semaphores must not have any relation to native threads or number of
cores. It's just a language level abstraction, nothing more. In that
case, i can't see how 'manual fine grained locking' can do any harm.
If you need to synchronize access to some object you simply can't
avoid that - at any level of abstraction (being in Erlang or OS, or
assembler).


--
Best regards,
Igor Stasenko AKA sig.

On 10/21/07, Igor Stasenko <[hidden email]> wrote:
>
> Hehe, then all we need is to implement ST with Erlang and we are fine. Yes? :)

There is always room for improvement.  Especially when we start
getting more flexibility on the hardware side.  But Erlang shows a
good way of dealing with concurrency that Smalltalk can learn from.

> I'm really pointing on, how efficient it can be (depends on proposed
> solutions) and what we can do to make good VM competing by speed with
> other language platforms.
> If we not taking speed into account, then there's nothing to talk about.
>
> And don't tell me that trying to make ST to run as fast as can is
> pointless...  Such thoughts are only for people, who taking a car and
> drive to wall-mart to buy a glass of water, located in 20 feets from
> their house.

Of course I care about speed.  I have a few ideas for speeding Squeak
up myself.  But in this case don't assume that message passing is
fundamentally slower.  Keep in mind that in a pure message passing
environment there are no locks to slow everything down, and the system
is easier and more likely to be designed to maximize concurrent
operations.  So I would expect it to be faster then other approaches
as the scale gets larger.  Yaws vs. Apache is a perfect illustration
of this.

> As side note, i don't want to make one ST Process === single native
> thread. Such solution is really 'obsolete' and lead to nowhere. I'm
> talking about VM which conserves all CPU(s) power while managing
> execution/GC seamlessly to language. The in-language Processes and
> semaphores must not have any relation to native threads or number of
> cores. It's just a language level abstraction, nothing more. In that
> case, i can't see how 'manual fine grained locking' can do any harm.

The harm is that it's simply the wrong abstraction.  Having the option
there leads people to use it and gives us a code base that using a
model that can't scale or compose.

> If you need to synchronize access to some object you simply can't
> avoid that - at any level of abstraction (being in Erlang or OS, or
> assembler).

That's the point: you *don't* have synchronized access to any object.
All you have is messages.  Think of it as an OO view of processes.
You can't see what's inside, you can only ask the process to do things
on your behalf.

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.
 
s-easy.html)

On 21/10/2007, Jason Johnson <[hidden email]> wrote:
If there's nothing else, which can be a replacement to this model ,
then you don't have a choice, but use above.

Again, a question raised: how to ensure that messages are passed in
correct order and  make sure that messages are delivered?
Now lets look inside: to make it working properly, you need to
implement a message queue. And queue means that you must make an
'enqueue' and 'dequeue' operations  synchronized.
And that's exactly what i mean: even if you hide the concurrency
problems from the eyes of developer, this is not means that problems
are gone: now you have to deal with them by own.
If you know another way(s) how to make proper message passing scheme
without using synchronized object (such as queue), i am all ears.

--
Best regards,
Igor Stasenko AKA sig.

Il giorno lun, 22/10/2007 alle 10.49 +0300, Igor Stasenko ha scritto:
The Erlang way: don't care about the order of arrival of the messages,
and let the developer care about that when it's important.

        Giovanni

On 22/10/2007, Giovanni Corriga <[hidden email]> wrote:
Yes, a simple example when i need to have correct order:
Collection>>do:

to print an array i'll have all items ordered from start to end , not
in random order.

And of course there are cases, when i don't need to have items
iterated in specific order. When i simply need to visit all items in
collection to send a message to them.

So, we need at least 2 messages to reflect a different behaviour:
#do:
and
#orderedDo:

and that's only the simplest case...

>         Giovanni
>


--
Best regards,
Igor Stasenko AKA sig.

Are you sure Igor? why you will a developer use an OrderedCollection if
he/she don't care about order? I think is more proper to use a aSet or aBag
even to perform something to the elements of that ordered collection in an
unordered way instead of (pre)asuming how #do: implements the traversal.

Perhaps you found another contraexample/s.

Cheers,

Sebastian

On 22/10/2007, Sebastian Sastre <[hidden email]> wrote:
Well, its maybe not a proper example, i just wanted to show, that we
will need changes to codebase (not only VM) to better support of
parallelism.

>
> Cheers,
>
> Sebastian
>
>
>


--
Best regards,
Igor Stasenko AKA sig.

1. For the correct order: I understand that Erlang is open so, to some
point, nothing stop us from looking that how-tos on how Erlang's VM makes
the message passing in correct order right? Seems to me that somehow they
solved that question and probably we can study how assimilate that virtue.
2. For ensuring messages sends: "send and pray"

That way when a smalltalk's erlangized message send is in a process that
terminates it should end with some cause for the act of finish. Maybe this
will allow for instance to implement DNU: the VM don't find a proper method
in the object to receive that message so it terminates the process stating
that as cause.

Cheers,

Sebastian

On 22/10/2007, Sebastian Sastre <[hidden email]> wrote:
While reading this topic, i googled, just to look what solutions are
found in this area for non-locking queues.
There is no wonder (still) - they all based on atomic CaS (Compare and
Store) processor instructions. Its of course interesting how Erlang
manages message passing, but i doubt that it based on something much
different.

> 2. For ensuring messages sends: "send and pray"
>
> That way when a smalltalk's erlangized message send is in a process that
> terminates it should end with some cause for the act of finish. Maybe this
> will allow for instance to implement DNU: the VM don't find a proper method
> in the object to receive that message so it terminates the process stating
> that as cause.
>

An 'erlangenization' of sends mean that we need deal differently with
contexts. I think best way for this, is to rethink a context to make
it look closer to what is a process in Erlang.
Yes, we must pay the price of making all contexts be real objects for
each message send, so we might expect a real slow-down of single
thread execution.
Then the only way how we could regain this loss is to use highly
parallelisable algorithms.

> Cheers,
>
> Sebastian
>

--
Best regards,
Igor Stasenko AKA sig.

> > Perhaps you found another contraexample/s.
>
> Well, its maybe not a proper example, i just wanted to show,
> that we will need changes to codebase (not only VM) to better
> support of parallelism.
>
I see your point. Will be possible that we make a basic early estimation of
how big the codebase earthquake will be? If we define that essential parts
to run system should work as survive, do you think will be feasible to
survive?

Cheers,

Sebastian
PS: Survivors will be stronger for sure ;-)

But I think that until we have async CPU's there allways have to be
implemented someway like that. I see it as a hardware limitation not as a
problem per se. My point is, as you say, that even with that it's very
interesting how they managed to take advantage of it and make such a good
message passing machine and feed the wonder of it being assimilable by the
objects paradigm.
I see that consequence but we are forced to think big by healty trends.
Systems todays are kind of optimal for monocore CPU's because they was not
designed for multicore and the adaptation to multicore CPU's has a tradeoff
of releasing that optimization for single processes. But that is a worry
just for what, one or two years? is a very short duration of time to worry
about for. Future seems to have all in favor of parallelization. This is all
about that. Hundreds of cores maybe higher orders of magnitude.

        Cheers,

Sebastian