Lots of concurrency

Lex Spoon lex at cc.gatech.edu
Thu Oct 18 23:12:20 UTC 2001


> 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.

I'm not sure you can get rid of the shared state so easily, however. 
Consider a Cell object, with two messages #set: and #get.  The cell's
instance variable can only be accessed directly by Cell itself, but
because of these accessor methods, the result is the same as if the
variable really was directly accessible.

For bank accounts, designing your messages so that they *don't*
interfere is very tricky!  Just the fact that you only interact via
messages doesn't buy you safety from inconsistent states.  In your
example, any time someone tries to do an update of the bank account with
multiple messages, horribly complicated stuff can happen if the messages
from multiple updates get interleaved.  A good designer will be careful
to avoid this, and it's difficult stuff.

So, it seems what you are suggesting is a programming style that is
already available.  Further, even in the IMHO very elegant parallel
system you describe, you could still program in an inferior style where
you have lots of expectations about other objects' states.  The goal,
then, must be that the new language makes the better style easier, or
the worse style harder, or something along these lines.

Am I in the ballpark?


-Lex




More information about the Squeak-dev mailing list