Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

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]
[Eily]: you could tie a variable into not having the same value each time, if you like to make people who try to debug your code facepalm
[Corion]: perl -wle 'package o; use overload q("") => sub {warn "str"; ""}, bool => sub{warn "bool"; 1}; package main; my $o={}; bless $o => o; print "Yay" if ($o && !length($o))'
[Corion]: But people writing such code should document the objects they construct and why it makes sense for an object to be invisible as string while being true in a boolean context
[hippo]: That's equal parts clever and horrendous.
[Eily]: the overload version wouldn't return true with "$x" && !length $x though, I guess
[hippo]: The more I look at this code, the more $x is a plain old scalar and the more this condition will never be true. I'm calling it a bug at this point.
[hippo]: Thanks for your input which has soothed my sanity (a little)
[Corion]: Eily: Sure - if you force both things into stringy things, then you break that magic. But that would also mean that you changed the expression, as now $x = 0.00 will be true instead of false as it were before
[Corion]: Ah no, at least in my feeble experiments that doesn't change the meaning
[Corion]: We sell sanity in small packages ;)

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (8)
As of 2017-07-27 13:42 GMT
Find Nodes?
    Voting Booth?
    I came, I saw, I ...

    Results (413 votes). Check out past polls.