Lots of concurrency

Andreas Raab Andreas.Raab at gmx.de
Fri Oct 19 09:22:23 UTC 2001


Lex,

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

No it's not. It's entirely different. The critical issue is "simultanous"
access (as Ken pointed out). If you allow simultanous access you cannot
guarantuee that the object is in a consistent state. As long as it is,
there's not problem with #get or #set: - but if you send any of these
_while_ some other thread is modifying the object it may just be in some
inconsistent state. It's basically transaction handling.

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

That was exactly the point Ken was making :-) If you _do_ allow interleaves
of the form you are describing then you're in fact in deep trouble. But he
was explicitly saying that he wants to change things "so that each object
has its own thread and no thread has more than one object". Note that this
has interesting implications for good design; a poorly implemented update of
the form:

	someAccount setAmount: someAmount getAmount + delta.

(modifying the object from the outside) is doomed to fail. You _must_
implement something like:

Account>>addAmount: delta
	amount := amount + delta.

That is fundamentally good because it encourages encapsulated and "service
oriented" design (rather than getters and setters we have a set of useful
services in the object).

> So, it seems what you are suggesting is a programming style that is
> already available.

Yes, but certainly not in Smalltalk ;-(

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

That seems very hard. See above. You are basically forced to think in
services because you may not be able to rely on getting the same result
twice if you call the same getter.

> The goal,
> then, must be that the new language makes the better style easier, or
> the worse style harder, or something along these lines.

See above.


Cheers,
  - Andreas





More information about the Squeak-dev mailing list