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

Andrew Francis andrewfr_ice at yahoo.com
Wed Apr 8 20:55:18 CEST 2009


Hi Richard:

--- On Fri, 4/3/09, Richard Tew <richard.m.tew at gmail.com> wrote:

Sorry for being so tardy in responding. And thanks for the helpful feedback.

> The best time to try out something like this, is of course
> when the problem unexpectedly arises.  Unless anyone has any
> outstanding deadlocks they are working around, it might be hard to do
> this.

Well from reading this mailing list, I have seen a few examples of developers complaining about deadlock. So deadlock does happen. The problem is recognizing it. It would help if I had more examples other my own. I am still trying to figure out the limits of my approach. I want to punch holes in the detector.

> It might be worthwhile do something along these lines:

The semester ends soon so I can do most of this. Also I would need an account.

> Personally, I prefer a postmortem approach like this:

http://code.google.com/p/stacklessexamples/source/browse/trunk/libraries/uthread-ccp/uthread.py#660

I find this URL very helpful. I haven't played with frames and traceback so I found the example helpful. Yes, it is useful to give stuff like the line number. 

This may also get me into looking at debugging.

> Place the deadlock detection at the lowest level and
> periodically monitor unexpected behaviour.  Then when unpredictable
> behaviour occurs in a live situation, which is not likely
> reproducible in a test environment, postmortem information is available.

I am not sure what lowest level means....

Well the way the detector currently works is that it runs once the Stackless Scheduler has decided there is deadlock. Perhaps a more obtrusive detector could wrap channels, hook into schedule.call_back, execute and throw an exception. However I doubt if this is much better.

I feel, provided the detector works on all but the most trivial examples, and one is scared of deadlock, the programmer will throw in the few extra lines of code (registerResources). 

> And unpredictability in my experience, tends to be best
> demonstrated by as full a picture of the logic flow as possible.  

Yes I agree. Let me play with this.

>This means a call stack with local variables.

Well the detector as it stands, ought to tell you about the contentious channels involved in the deadlock. I suspect analysing the local 
variables will give you all the channels available to the deadlocked tasklet. This is more than you may need. 

Thanks for the suggestions.

Cheers,
Andrew





      




More information about the Stackless mailing list