Lots of concurrency

Ken Kahn kenkahn at toontalk.com
Thu Oct 18 18:14:51 UTC 2001


Lex Spoon wrote:

> Now here's where I get a little lost:
>
>
> > I agree. Mixing concurrency and shared state causes headaches that we
all
> > want to avoid. My answer is that there is no shared state and no process
> > state (there is no *position* in a computation to worry about - remember
I'm
> > getting rid of sequential composition). There are just concurrent
objects
> > that send messages asynchronously. E.g. actors. Though I'm arguing for
> > something a bit more flexible than actors where there can be multiple
mail
> > boxes, where mail boxes are first class, etc.
>
>
> I don't see how this can work in practice.  For a simple example, how
> would you do BouncingAtomsMorph in your system?  In Squeak, each atom
> currently has a position stored in an instance variable -- i.e., state.
> How do you get rid of the state in something like an atom bouncing
> around?  Move it into the messages?
>
> How does an atom decide when it is close to the edge of the screen and
> needs to bounce into a different direction?  And for bonus, how do atoms
> infect each other, i.e., how do you tell when two atoms of different
> color are near each other?
>

Sorry about the confusion. When talking to procedural programming types I
use the phrase "shared state" to mean data that can be altered by multiple
threads. In the context of pure object-oriented programming I should explain
this differently. I am not proposing to get rid of state. I agree with you
that that doesn't work despite the efforts of functional programming
researchers.

What is it that causes problems when mixing state and concurrency? It is
when there can be simultaneous access to the same state. If two threads are
both running code for a bank account object then those threads may interfere
with each other and leave the bank account in some inconsistent and
unpredictable state. I want to change things so that each object has its own
thread and no thread has more than one object so this problem goes away. And
asynchronous message sending means that if A sends B a message M1 and then
sends B message M2 that other messages from others might arrive between M1
and M2 and so A can't assume that B hasn't changed in the interim.

Maybe one way to communicate these ideas is to imagine that each object is
running on its own server. The server maintains the state of the object. You
have concurrency without race or deadlock worries. Just performance worries
;-)

Best,

-ken kahn ( www.toontalk.com )







More information about the Squeak-dev mailing list