Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

C++ Concurrency Debugging techniques

 
Varun Narang
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Anthony Aj Williams
author
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.


 
Chun Chu
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic