From: Kirit Sælensminde (kirit.saelensminde_at_[hidden])
Date: 2008-01-07 08:14:05
I think I would second this comment from Johan.
Johan Nilsson wrote:
> As a pretty experienced TFD:er with threaded code, I should give you a
> warning though: the race conditions and deadlock sequences that you are
> foreseeing, and therefore writing tests for, are generally the ones that you
> will handle correctly. You should of course be writing tests for those as
> well as anything else, but there is no real replacement for running
> "higher-level" unit tests as well with a high amount of contention involved.
It isn't just interleaving that you're going to have problems with here.
In these days of multi-cores and SMP with non-shared on-core caches
you're also looking for visibility problems where a memory write doesn't
appear for a thread on another core/processor -- something else you
might be able to simulate, but it would be complex too.
As Johan says, high level tests will find these, but you need to build
high stress environments. Any testing you do where threads aren't on
separate cores isn't going to be worth the runtime it takes them to
execute either. You also have a number of interesting potential problems
due to where objects are placed in memory (i.e. things will be very
different if things used by separate threads on different cores happen
to be in the same cache line).
Using co-routines is an interesting idea, but for the things that they
will let you test formal proofs may not be any more work and may give
more confidence than testing.
I'm sure none of this is stuff you aren't already thinking about though.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk