New subject: Lots of concurrency

25 Oct 2001


      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 )

RE: Lots of concurrency