Multy-core CPUs
Andreas Raab
andreas.raab at gmx.de
Thu Oct 25 21:08:08 UTC 2007
Peter William Lount wrote:
> When a message is sitting in an inbound queue on a process waiting for
> that process to do get to it it is in essence blocked until it gets
> processed. If the process is only processing one inbound message at once
> it is possible for a dead lock to occur when multiple processes are in a
> similar situation with each other. Both processes waiting for the
> message that would let them continue which is sitting blocked on the
> other's queue. That's all. Classic deadlock case.
Deadlock can only happen if one process waits for another. E does
*never* wait, there is no wait instruction. Instead, it schedules a
message to be run when the desired computation completes. This leaves
the Vat free to execute other messages in the meantime. In Croquet, this
looks like here:
"future is Croquet's variant for sending async messages"
promise := rcvr future doSomething.
promise whenResolved:[:value|
"do something with the result of the computation
this block will executed once the concurrent computation
is completed and the response message is being processed
in this Vat/Island."
].
Because there is no wait, "classic deadlock" simply cannot happen. There
is an equivalent situation which is called "data lock" where circular
dependencies will cause a computation not to make progress (because a is
computed in response to the completion of b, b in response to completion
of c and c in response of completion of a). But there are *major*
differences to deadlocks: First, datalock is deterministic, it only
depends on the sequence of messages which can be examined. Second,
because the Vat is *not* blocked, you are free to send further messages
to resolve any one of the dependencies and continue making progress.
In other words, the "control flow problem" of deadlock has been turned
around into a "data flow problem" (promises and completion messages)
with much less dramatic consequences when things go wrong.
Cheers,
- Andreas
More information about the Squeak-dev
mailing list
|