[Stackless] Example Re: Requesting Comments for a Deadlock Detection Module

andrewfr_ice at yahoo.com andrewfr_ice at yahoo.com
Fri Apr 3 21:02:16 CEST 2009

Hi Christian:

--- On Fri, 4/3/09, stackless-request at stackless.com <stackless-request at stackless.com> wrote:

> I don't really get where the problem is. It is IMHO
> just fine to detect and analyze this first simple deadlock.
> How would you think to do more than this? The example
> has a very predictable future, because it is constructed
> this way.

I have included a more complex example. The example comes from a problem I had in December 2005 when I was first starting to learn Stackless Python. I was trying to figure out how to implement WS-BPEL links (links are a workflow construct - links impose a logical ordering on the tasklets). 

Asgeir Ingvarsson's analysis of the problem was on the money. My detector is based on Asgeir's observation:

<blockquote Asgeir>
Well as I understand it, E has only announced it's intention
to read on CtoE and is blocked before it can call receive on BtoE.
**Therefore the scheduler has no knowledge of E's intent to read on BtoE.**

Also, it seems to me that C is waiting for B not E
   E is trying to read from C
   B is trying to write to E
   C is trying to read from B

(** my emphasis **)

Here are the references:


Using the DeadlockDetector, this is the output:

[(D, C, CtoD), (C, B, BtoC), (B, E, BtoE), (E, C, CtoE)]

Note, I am not sure why occasionally the detector adds the extra node, but it always shows the cycle. I have look into this.

Again, Christian, thanks for your comments. I wish people would try out the detector - so I can get feedback and improve it.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: december2005.py
Type: application/octet-stream
Size: 3075 bytes
Desc: not available
URL: <http://www.stackless.com/pipermail/stackless/attachments/20090403/6dc1fa6c/attachment.obj>

More information about the Stackless mailing list