Lots of concurrency

Ken Kahn kenkahn at toontalk.com
Thu Oct 25 20:54:34 UTC 2001


Ned Konz wrote:

But ToonTalk itself still provides support for sequential programming (from
my brief experience with the demo): you program a robot by having it record
your (sequential) actions. Though by not allowing a robot to give a box to
another robot, you're disallowing the equivalent of subroutine calls
(right?).

Isn't it possible in ToonTalk to run into the same kind of problems with
concurrency that you describe with other systems?

For instance, wouldn't it be possible to do the bank account example in
ToonTalk in such a way that you could have inconsistent results, that is,
the
same as the problem with:

accountA balance: accountA balance - 50.
accountB balance: accountB balance + 50.

You think about solutions from the point of view of a computer scientist
who's familiar with all the potential problems of concurrency; would it even
occur to a kid or programming newbie to _not_ do it unsafely in ToonTalk?

-------------------------

The sequence of actions that you train a ToonTalk robot to do are send
message, create a new process, perform some basic operations like
arithmetic, and update the local state. Message sending and process spawning
can be executed in any order (though I admit for clarity they are performed
in the same order as when the robot was trained). They can be executed in
any order since they have a semantics of EVENTUALLY doing something.
Completing a message send might take a nanosecond or a year but ToonTalk
doesn't wait for it finish before proceeding to the next action. Similarly
for process spawning - there is no guarantee as to how soon that process
will start running. If ToonTalk supported artithmetic and the like by
message sending then this would be the end of the story. But some
compromises were made regarding primitive operations. One price of making
everything visible and tangible as in ToonTalk is that it is hard to hide
cheating. I think it was Dan Ingalls who said the implementor must cheat,
but not get caught. It is so much easier to get caught in ToonTalk.

One can program the bank account so some inconsistencies can occur but a
whole class of inconsistency is avoided: those inconsistencies caused by
multiple threads simultaneously running the methods of the same object. And
if all the methods of an object are commutative (e.g. "change balance by"
rather than "set balance to") then it can't become inconsistent. And
consistency accross objects will happen when the system becomes quiescent
(which may never happen).

By the way, the bank transfer example doesn't really require a transaction.
Just withdraw 50 from A, wait for an acknowledgement, and then deposit the
50 in B. And the system might profit from a few milliseconds of float ;-)

If kids do implement "set balance" and "get balance" methods and then find
their system isn't quite consistent then this might be a great learning
opportunity. Especially in an environment where they can see what is
happening. And to those who think kids aren't going to implement banking
systems - the same issues come up for score keepers in games.

Best,

-ken kahn ( www.toontalk.com )





More information about the Squeak-dev mailing list