Thread question.... detecting deadlocks?
I assume I will find the answer to this right after hitting "send", but my googling so far has turned up nothing. Is there a way to turn on deadlock detection in the thread library somehow? I realize it would be slow, and possibly change the behavior of my program so as to give a "false negative", but I'd still like the option. Sigh. (note to self: don't hold locks across a function, unless you know exactly who and what that function will call).
On 3/8/2011 12:29 PM, Igor R wrote:
This is not really the aswer to your question, but if you work with MSVC, in case of deadlock you can just push "pause" button and see what happens to every thread.
Yeah, that's how I found this latest programming screwup on my part, attaching the debugger after the application went silent. I was just wondering if there was some quick #define to enable a debugging mode where I'd get an exception or something I could log when that happened, as opposed to the program just locking up.
I was just wondering if there was some quick #define to enable a debugging mode where I'd get an exception or something I could log when that happened, as opposed to the program just locking up.
You can use timed_lock(), time_wait() etc in debug mode. Set the time period to some reasonable value and raise an exception if the wait failes.
On Tue, Mar 8, 2011 at 1:35 PM, Eric J. Holtman
On 3/8/2011 12:29 PM, Igor R wrote:
This is not really the aswer to your question, but if you work with MSVC, in case of deadlock you can just push "pause" button and see what happens to every thread.
Yeah, that's how I found this latest programming screwup on my part, attaching the debugger after the application went silent.
I was just wondering if there was some quick #define to enable a debugging mode where I'd get an exception or something I could log when that happened, as opposed to the program just locking up.
Maybe my experience with multithreading is too limited, but I have generally been successful in preventing deadlock and race conditions by using a blend of analysis and mutex semaphores and counting semaphores. My approach can be likened to choosing between catching a divide by zero floating point exception and preventing divide by zero errors before they can happen. For that, a simple check on the divisor is sufficient to both prevent the floating point exception and ensuring the program behaves rationally in those cases that would otherwise produce such an exception. Similarly, my preference is to make threads relatively isolated, so they don't share resources. In the circumstance where shared resources are involved, I try to ensure that while any thread can have read access, only one has write access, and that one can be constructed like a server, to listen for write requests, and it handles queuing these requests, and when the shared resource(s) is free, obtains exclusive rights to the resource until all pending writes are complete. The bottom line is I try to design things in such a way that, with a sensibe architcture and judicious use of the right semaphores, deadlocks and race conditions are prevented, eliminating the need to detect them after the fact. So, if I can answer a question with a question, is it not possible to always prevent deadlocks and race conditions by careeful analysis and use of the right suite of semaphores, or it is just that my experience with multithreading is too limited to have seen those cases where my approach is insufficient? Cheers Ted
On 3/8/2011 1:00 PM, Ted Byers wrote:
So, if I can answer a question with a question, is it not possible to always prevent deadlocks and race conditions by careeful analysis and use of the right suite of semaphores, or it is just that my experience with multithreading is too limited to have seen those cases where my approach is insufficient?
Oh, I completely agree with you. But sometimes, you just forget where the boundaries are in your application code, and well, then . . . . . My error that caused the deadlock was certainly something I never should have done, but it (as always) happened so rarely that it was hard to replicate (and in some cases, hard to notice, as it only locked two threads out of many). Likewise: I wouldn't run my application with STL iterator debugging enabled, but it's great during development for those occasional brain farts.
"Eric J. Holtman"
Is there a way to turn on deadlock detection in the thread library somehow?
There is no deadlock detection provided as part of boost.thread. You can use external tools such as Intel Thread Checker to detect deadlocks in code using Boost.Thread. Alternatively, deadlock detection is provided as part of my commercial implementation of the C++0x thread library (see sig). Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
On 3/9/2011 2:41 AM, Anthony Williams wrote:
Alternatively, deadlock detection is provided as part of my commercial implementation of the C++0x thread library (see sig).
Aha! I *knew* I had read about deadlock detection somewhere, now I remember where. I think I'm "stuck" with boost for a while, I backed myself into a corner where I really like interruptions, and I don't think C++0x offers that.
"Eric J. Holtman"
On 3/9/2011 2:41 AM, Anthony Williams wrote:
Alternatively, deadlock detection is provided as part of my commercial implementation of the C++0x thread library (see sig).
Aha! I *knew* I had read about deadlock detection somewhere, now I remember where.
I think I'm "stuck" with boost for a while, I backed myself into a corner where I really like interruptions, and I don't think C++0x offers that.
No, interruptions are not part of the C++0x thread library. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
participants (4)
-
Anthony Williams -
Eric J. Holtman -
Igor R -
Ted Byers