GeeCON Prague 2014*
The moose likes C / C++ and the fly likes C++ Concurrency Debugging techniques Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Languages » C / C++
Bookmark "C++ Concurrency Debugging techniques" Watch "C++ Concurrency Debugging techniques" New topic
Author

C++ Concurrency Debugging techniques

Varun Narang
Ranch Hand

Joined: Nov 19, 2004
Posts: 30
Hi,

This always kept me wondering as in how do I debug a code written to run parrallely. While normal debugging technique using an attached debugger holds the program in a place, it doesn't really behave 'concurrent'. Are there any rules of thumb, which one need to keep in mind while trying to troubleshoot such a problem.

Best,
Varun


Your computer system is like AC, it's of no use when you open Windows ;)
Anthony Aj Williams
author
Ranch Hand

Joined: Jun 10, 2011
Posts: 56
Varun Narang wrote:[This always kept me wondering as in how do I debug a code written to run parrallely. While normal debugging technique using an attached debugger holds the program in a place, it doesn't really behave 'concurrent'. Are there any rules of thumb, which one need to keep in mind while trying to troubleshoot such a problem.


Testing and debugging concurrent code is covered in chapter 10 of my book.

Debugging concurrent code is HARD. I recently fixed a race condition where it took many runs of the application to reproduce the problem, and the symptoms (random crashes) did not give any indication of the cause.

My best suggestion is to try and write your code as a set of independent threads that can be tested separately. If you keep the shared state to a minimum, and have your threads communicate with small well-defined and well-tested interfaces then it makes things so much easier. For example, in chapter 4 I give an example of multiple threads communicating exclusively with messages. Each thread can thus be tested independently, as the behaviour depends entirely on the sequence of messages in the queue. The only part that then requires intensive testing in a multithreaded environment is the queue itself, which is a much smaller block of code to reason about.

If you are trying to debug a problem in existing code, then try and reproduce the problem in a small test, to eliminate as much as possible of the code involved, and make it easier to reason about.



Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/
just::thread C++11 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
Chun Chu
Greenhorn

Joined: Jan 11, 2011
Posts: 15
Agreed with what Mr. Williams suggested.

You really want to keep data sharing as minimum in a multi-threading application. Not only it makes debugging easier it also makes testing easier.

In an idea world, you probably want each thread to hold its own copy of data so it doesn't need to rely some other classes for information.

Thread Local is a good solution for it.

aahh, this spawn another question, does the new C++0x introduces Thread Local? I have only dealt with Thread Local using the ACE Framework
Anthony Aj Williams
author
Ranch Hand

Joined: Jun 10, 2011
Posts: 56
Chun Chu wrote:this spawn another question, does the new C++0x introduces Thread Local? I have only dealt with Thread Local using the ACE Framework


Yes, there is now a keyword thread_local which marks a variable as thread-local.

 
GeeCON Prague 2014
 
subject: C++ Concurrency Debugging techniques