aspose file tools*
The moose likes C / C++ and the fly likes Debugging Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Languages » C / C++
Bookmark "Debugging" Watch "Debugging" New topic
Author

Debugging

Jonathan Smiths
Greenhorn

Joined: Jan 29, 2010
Posts: 15
Hi Mr. Williams,

I just finished a course on concurrency at my study.
It appeared to me that while concurrent software can be much more efficient than other software, it is really hard to debug.
I often got really unpredictable errors or errors without any error message while programming concurrent software in C++.

Are there any debuggers specifically designed to debug concurrent software that you can recommend to me?

If not so, what is a good way to get a grip on debugging concurrent software manually?

How would you test concurrent software, knowing that there is often a small chance the threads could interfere, which may not show up the first time testing?

Thanks in advance,

Jonathan
Anthony Aj Williams
author
Ranch Hand

Joined: Jun 10, 2011
Posts: 57
Jonathan Smiths wrote:
It appeared to me that while concurrent software can be much more efficient than other software, it is really hard to debug.


Agreed.

Jonathan Smiths wrote:
Are there any debuggers specifically designed to debug concurrent software that you can recommend to me?
If not so, what is a good way to get a grip on debugging concurrent software manually?


I'm not aware of any debuggers specifically designed to debug concurrent software. There are tools such as Corensic's Jinx which can help pinpoint problems by identifying data races in your code, tools such as relacy that can examine your code for correctness before release, and library facilities such as the deadlock detection mode in my just::thread library.

Jonathan Smiths wrote:
How would you test concurrent software, knowing that there is often a small chance the threads could interfere, which may not show up the first time testing?


Design your software so that the threads don't "interfere" with each other.

The easiest way to handle concurrent code is to design it so each thread is independent and can be tested separately.

For example, if your threads use message queues for interacting then you can test each thread independently, and verify that the correct sequence of messages is sent in response to each possible incoming sequence. Assuming the message queue works correctly (which only has to be written once), and you got the message sequences right, then your code will work when everything is linked together.

For testing the core parts of the code that really need multiple threads --- the data structures that will be shared, such as the message queues just mentioned --- then you need more intensive testing. Ideally, run your tests on a variety of CPUs, with a variety of processing cores --- more/fewer cores than the number of threads used in the test, multiple processors vs one multi-core processor, and so forth. Use relacy and jinx to test your code. Build your tests so that the critical parts are being tested in multiple combinations, many many times.

One thing I like to do is to run all the tests on background threads. The main thread sets up the test and spawns the threads, which all block on a synchronization object (such as a future or condition variable, or even spinning on an atomic variable). Once all the threads are running, the main thread triggers the synchronization object, so the threads start running the test. This avoids the potentially large overhead of spawning threads interfering with the test outcomes --- otherwise you might find that one background thread has completed before another has even started. Of course, you are still subject to the OS scheduler but it does help.


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
Madhan Sundararajan Devaki
Ranch Hand

Joined: Mar 18, 2011
Posts: 312

One simple standard practice will be to use logging to trace/debug your multi-threaded application.


S.D. MADHAN
Not many get the right opportunity !
 
jQuery in Action, 2nd edition
 
subject: Debugging