Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

Re^2: UnitTesting multi-threaded apps

by alain_desilets (Beadle)
on Mar 11, 2011 at 12:19 UTC ( #892642=note: print w/replies, xml ) Need Help??

in reply to Re: UnitTesting multi-threaded apps
in thread UnitTesting multi-threaded apps

You wrote:
It's well known that unit testing and multi-threading don't mix very well. This is still an active area of research. I touched on this topic recently in Nobody Expects the Agile Imposition (Part VI): Architecture (see the "Unit Testing Concurrent Code" and "Testing Concurrent Software References" sections).

So far, I haven't found it hard to write tests to verify the multi-threaded parts. For example, I have a class called JobQueue which acts as a shared object between a Boss thread and a Worker thread. I have been able to write tests to verify that two separate thereads can indeed use this class to communicate in a Boss-Worker mode.

My problem is that I can't run the JobQueueTest in the same run as some other tests that use non thread-safe modules.

I guess I could write a shell script that starts two processes, one to test the thread-safe bits, and one to test the non-thread safe bits.

You wrote:
In practice, I usually unit-test my software components in a single threaded environment only.

This of course, assumes that your program can run in both modes: multi-threaded and single threaded. This makes the design more complex, but I guess it's a good idea anyway, given that perl threads are still somewhat bleeding edge (in other words, it would good for me to make sure that I can fallback on single threading if it turns out that multi-threading is causing too many problems). I think it should be possible for me to do that.

You wrote:
For flushing out concurrency bugs in multi-threaded code, the most effective (if crude) technique I've found is good tracing code at just the right places, combined with understanding and reasoning about the multi-threaded code and performing experiments. One especially useful experiment is to add "jiggle points" at critical places in your concurrent code and have the jiggle point either do nothing, yield, or sleep for a short interval. There are more sophisticated tools available, for example IBM's ConTest, that use this approach.

Can you elaborate on the jiggle point technique?


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://892642]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (4)
As of 2017-03-22 23:08 GMT
Find Nodes?
    Voting Booth?
    Should Pluto Get Its Planethood Back?

    Results (277 votes). Check out past polls.