Hi Christian: --- On Fri, 4/3/09, [email protected] <[email protected]> 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 </blockquote> (** my emphasis **) Here are the references: http://www.stackless.com/pipermail/stackless/2005-December/000290.html http://www.stackless.com/pipermail/stackless/2005-December/001380.html http://www.stackless.com/pipermail/stackless/2005-December/001921.html 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. Cheers, Andrew
december2005.py
Description: Binary data
_______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
