Lots of concurrency
Mark van Gulik
ghoul6 at home.com
Sat Oct 20 02:44:37 UTC 2001
Is everyone missing this or what? There is a *huge* difference
between what has been proposed and transactional computation.
Transactions require Atomicity, Consistency, Isolation, and
Durability. What has been proposed is just Atomicity. Period.
While that is a very useful thing to have, it's never going to
be enough.
To use a dead simple example from the current domain, how do you
transfer funds from one bank account to another? Without all
four of the above properties, there is no reliable mechanism to
do so (it might be possible with only three, but I'm not
certain).
Within the main proposal of serialized processing of incoming
messages, it seems that there is a subpropsal for a design
pattern that says these messages should be commutative. Good.
The Scamper example can probably be expressed in a simple state
machine, and (limited) commutativity can be ensured by ensuring
the state machine is fairly complete and well-defined.
The advantage of commutative operations is that you don't have
to care what state the target object is in at the point in time
that you send a message. If you're incrementing a counter,
it'll get incremented whether or not other increments have been
processed. You can even have a linear "set" operation that
writes a value and sends back a message containing the old
value. That will let you build up nice properties like
"Conservation of Money", which accounting systems simply *have*
to have. A language with linear types could even support such a
concept *provably*.
More information about the Squeak-dev
mailing list
|