David Chase wrote:
I don't know if this has much relevance to Squeak, but in my experience programmers, and I think people in general, are much happier thinking sequentially. The sort of bugs that occur with unstructured parallelism are just too Martian for most people to contemplate. On the other hand, if every method is "synchronized" (to use the Java phrase), it is generally too expensive, and also not enough (to refer back to someone else's transaction example -- books must balance).
Whether people are "happier thinking sequentially" is a very important question. [As an aside, people clearly don't think sequentially - the brain has huge amounts of internal parallelism. And I think it is just an illusion that this parallelism is only at a low level (e.g. neurons). Read Minsky's Society Theory of Mind ( http://www.media.mit.edu/people/minsky/ ) for example.]
Thinking sequentially about problems that are inherently concurrent is suboptimal. Here's an excerpt from "MultiLogo: A Study of Children and Concurrent Programming" ( http://el.www.media.mit.edu/groups/el/Papers/mres/MultiLogo/MultiLogo.html ) where a fourth-grade girl (F) who had programmed Logo for a year was asked to "program" a situation in which she had to sweep the floor and her brother had to set the table for dinner:
F: I'm going to tell him to start setting the table, which he won't do. Anyway, he starts on the table, then I go back and start sweeping.
M: So you're going to ask him to set the table, and then you're going to start sweeping.
F: But when I tell him to do it, he only does one plate. But there are five people that he has to set places for and he only sets one plate. Because he has to repeat this thing. And I have to repeat. I only make one stroke with my broom. But we have to repeat it forever. But there is no way both of us...
I think her problem is that her model of programming is sequential as a result of her year of Logo programming. And the world isn't sequential. Think of sports teams. Think of traffic. Think of the internal concurrency in walking. In games. Think about bank account transfers. The Incredible Machine. Cooking. An orchestra. And so on.
"Unstructured parallelism" is fine UNLESS the concurrent activities can interfere with each other. That's why I'm not excited about taking sequential languages and adding threads or the like. You need to redesign from scratch to deal well with concurrency.
There's been a lot of discussion here of transactions. I agree that programming transactions using locks is just "too Martian". [Maybe that's why the ToonTalk help character is Marty the Martian ;-)] Here's how I would program them in ToonTalk. I'd program a bank account robot to respond to a message to give exclusive attention. The message contains a nest where subsequent messages will arrive. (And probably a bird that is given an acknowledgement that the message was processed.) The robot takes the nest where messages normally arrive and stores it somewhere in its box and puts the incoming nest where that nest was. In case you want to back out of an aborted transaction the robot should have copied its box and stored it as well. Now when the sender of the message has exclusive control over this bank account. All of its messages go to the nest it sent and messages from anyone else go to the stored nest. To end exclusive control a message is sent releasing it and a robot handles it by throwing away the copy of the old state and the nest and puts the original nest back where it was. (And any messages that were sent in the meanwhile are still on top and are now processed). This isn't very complicated - I bet a typical 10-year old familar with ToonTalk can master this. As with any code, bugs are possible. The most serious one being to forget to end exclusive control when you are done.
I also think that truly asynchronous communication is a dubious idea. The worst parts of Java (the deprecated bits) are more or less asynchronous (Thread.stop,suspend,resume). We ended up (in our Java system) hiding almost all asynchrony; threads yield at well-defined points, garbage collection occurs at well-defined points, etc, all enforced by the compiler/VM (in the safe language, there are no infinite loops, period).
and in "Little Deadlocks and the Three Bears" by Jecel Mattos de Assumpcao Jr. ( http://www.lsi.usp.br/~jecel/stories/deadlocks.html ) he defines asynchronous:
"asynchronous - the synchronous messages used in CSP couple the communication of information with the communication of events. With asynchronous messages the two are separated (communication of event is then done with semaphores and similar structures) allowing great flexibility in system design. This also means there are great opportunities for mistakes, so understanding and debugging asynchronous systems is not a trivial task. "
These problems with asynchronous messages don't match my experience. Maybe these problems are completely a consequence of mixing asynchrony and sequential programming.
I am afraid that I am perhaps focusing on this at too low a level for this crowd, but the subject of the thread is "lots of concurrency", and I am not sure what that is really intended to mean. Normally, I think it implies performance.
To me concurrency means simultaneous activities (and if just running on a single processor then at least conceptually simultaneous). Parallelism (running on multiple CPUs under your control) and distributed programming (running on communicating computers typically controlled by different parties) are special cases. Simultaneous activities are a good idea when there is a conceptual match, when there are CPUs going idle, or when it is inherent (e.g. distributed computing).
Best,
-ken kahn ( www.toontalk.com )