On 10/21/07, Peter William Lount peter@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.....
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-memor...
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-...
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&am...
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.