Hi Rob,

SqueakElib sounds interesting. With all the links on this thread (pun 
intended) I have weeks of reading and absorbing to do.

My example below wasn't expressed as clear as it could be.

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.

I don't know if that is any clearer, hopefully it is.

All the best,

Peter



Rob Withers wrote:
> Hi Peter,
>  
> My response here is not formatted as I would wish, but is the imit of 
> my current technology.
>
> I work on SqueakElib, and though I am certainly no expert on E, I am 
> somewhat familiar with it's design and implementation.  That said, a 
> comment you made caught my eye...
>
>  
> > ----- Original Message ----
> > From: Peter William Lount peter at smalltalk.org 
> <mailto:peter at smalltalk.org>
> >
> > If a number of messages are waiting in the input queue of a process
> > that can only process one message at a time since it's not 
> multi-threaded
> > then those messages are BLOCKED while in the thread. Now imagine
> > another process with messages in it's queue that are also BLOCKED
> > since they are waiting in the queue and only one message can be
> > processed at a time. Now imagine that process A and process B each
> > have messages that the other needs before it can proceed but those
> > messages are BLOCKED waiting for processing in the queues.
> >
> > This is a real example of what can happen with message queues. The
> > order isn't guaranteed. Simple concurrency solutions often have 
> deadlock
> > scenarios. This can occur when objects must synchronize events or
> > information. As soon as you have multiple threads of execution 
> you've got
> > problems that need solving regardless of the concurrency model in 
> place.
>
> Messages don't get blocked, when they are queued for the Vat 
> (thread/process) to service them.  They do get queued when they are 
> sent to a Promise, but it does not affect the Vat.  When the Promise 
> resolves, the messages are forwarded to the Vat for processing, in 
> order, so partial msg ordering is maintained. 
>  
> Msg ordering is partial because of this case: object a in Vat A, 
> object b in Vat B, and object c in Vat C are intercommunicating.  Both 
> b and c have references to a.   At time t1, b sends msg m1 to a, at 
> time t2, c sends msg m2 to a, but there is higher network latency for 
> b, so m2 gets to a at t3 and m1 gets to a at t4 and they are out of 
> order from the remote invocation order.
>  
> I hope this helps.  Read more about Elib.
>  
> cheers,
> Rob
>
> ------------------------------------------------------------------------
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20071025/60b0dfcf/attachment.htm