Multy-core CPUs

Andreas Raab andreas.raab at
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.

   - Andreas

More information about the Squeak-dev mailing list