On 10/21/07, Peter William Lount <peter at smalltalk.org> 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.