post mortem after threading deadlock?
Is there any possibility of getting some post-mortem info out of a multi-threaded system whose threads are deadlocked?
You could attach to the process using a C debugger (e.g. gdb), and have a look at the C stacks of each thread. Then, you can look into the variables of the eval_code invocations to get a clue of what the Python stack is. Regards, Martin P.S. Isn't this off-topic for python-dev, and rather a question to python-list or python-tutor?
[suggestions elided - thanks, I will look into gdb's thread debugging capabilities] Martin> P.S. Isn't this off-topic for python-dev, and rather a question Martin> to python-list or python-tutor? Well sort of. However, if you read my problem as a thinly veiled enhancement request, the people most likely to be able to implement such a thing are on this list. I sort of suspect that from the Python level about all I can do today is what I'm already doing - poking around the various locks and semaphores that the threads all share. Skip
[Skip Montanaro]
... However, if you read my problem as a thinly veiled enhancement request, the people most likely to be able to implement such a thing are on this list. I sort of suspect that from the Python level about all I can do today is what I'm already doing - poking around the various locks and semaphores that the threads all share.
I've got better advice <wink>: Never use semaphores for anything. Never use locks except for dirt-simple one- or two-line critical sections. For everything but the latter, always use condition variables. They're the only synch protocol I've seen that non-specialist thread programmers can use without routinely screwing themselves. The genius of the condvar protocol is that, used correctly, you *always* run-time test your crucial assumptions about non-local state (and automatically do so under the protection of a critical section), and *always* loop back to try again if your hopes or assumptions turn out not to be true. This saves you from a universe of possible problems with non-local state changing in unanticipated ways. if-you-had-used-condvars-you-wouldn't-be-debugging-now-ly y'rs - tim
I've got better advice <wink>: Never use semaphores for anything. Never use locks except for dirt-simple one- or two-line critical sections. For everything but the latter, always use condition variables. They're the only synch protocol I've seen that non-specialist thread programmers can use without routinely screwing themselves. The genius of the condvar protocol is that, used correctly, you *always* run-time test your crucial assumptions about non-local state (and automatically do so under the protection of a critical section), and *always* loop back to try again if your hopes or assumptions turn out not to be true. This saves you from a universe of possible problems with non-local state changing in unanticipated ways.
I believe that Aahz, in his thread tutorial, has even more radical advice: use the Queue module for all inter-thread communication. It is even higher level than semaphores, and has the same nice properties. --Guido van Rossum (home page: http://www.python.org/~guido/)
[Guido van Rossum]
I believe that Aahz, in his thread tutorial, has even more radical advice: use the Queue module for all inter-thread communication. It is even higher level than semaphores, and has the same nice properties.
If they're *flexible* enough for Skip, I endorse Queues too. Else condvars are the bee's second-prettiest knees.
Tim> I've got better advice <wink>: Never use semaphores for anything. Tim> Never use locks except for dirt-simple one- or two-line critical Tim> sections. I didn't find either particularly difficult to work with. Guess I was fooling myself. ;-) Guido> I believe that Aahz, in his thread tutorial, has even more Guido> radical advice: use the Queue module for all inter-thread Guido> communication. It is even higher level than semaphores, and has Guido> the same nice properties. Ah, thanks! I saw the mention of Queues in his slides and thought he was talking about a queue class that he wrote as an add-on. It never occurred to me that it would be a core library module. doh! A queue is really what I want anyway. I'm sharing a limited pool of database connections between a (potentially large) set of threads. one-regulation-head-slap-has-been-administered-sir!-ly y'rs, Skip
Guido van Rossum wrote:
I believe that Aahz, in his thread tutorial, has even more radical advice: use the Queue module for all inter-thread communication. It is even higher level than semaphores, and has the same nice properties.
Not only that, Queue.Queue has the especially nice property of handling both data protection (mutexes) and synchronization. I'm following up primarily to announce that I've just uploaded my OSCON slides (new and improved!) to http:/starship.python.net/crew/aahz/ -- --- Aahz (@pobox.com) Hugs and backrubs -- I break Rule 6 <*> http://www.rahul.net/aahz/ Androgynous poly kinky vanilla queer het Pythonista I don't really mind a person having the last whine, but I do mind someone else having the last self-righteous whine.
participants (5)
-
aahz＠rahul.net -
Guido van Rossum -
Martin v. Loewis -
Skip Montanaro -
Tim Peters