Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

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?

Thx.


Comment on Re^2: UnitTesting multi-threaded apps

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://892642]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (15)
As of 2014-08-28 16:21 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (264 votes), past polls