[concurrency-interest] Is there something like an ordered or counting barrier

David Holmes dholmes@dltech.com.au
Fri, 31 Dec 2004 16:21:10 +1000


Oliver,

> Of course you have to be careful with the construction of such a test
> case, but - and this is what I am asking - what is the alternative?
> How do others test their lock classes? You need multiple threads, but
> then you need them to execute in a deterministic way to reproduce the
> test scenarios you want to check.

Like any class testing MT code ranges from basic black-box testing through
to complex white-box testing. Simple black-box tests can be used that
involve positioning threads at the right place eg. acquire a lock in one
thread then assert the lock reports that thread as the owner; that a tryLock
in another thread fails; that a Condition await/signal from another thread
fails etc.

Simple positioning can be done using synchronized sections, wait/notify or
things like semaphores and barriers - it all depends what conditions you are
trying to establish.

For white-box testing, the ability to setup the system state so that you can
test the code path you want to test, can prove to be prohibitive rather
quickly. And even if you can test a given code path, testing all possible
interleavings is impractical. Rather than try to perform such intricate
tests, people tend to move to the other end of the spectrum and look at the
stress tests that Doug mentioned. You check all the pre- and post-conditions
and all the invariants that you can - both in the "application" part of the
test and the lock class itself, then throw numerous threads at it from
different angles. Add in random sleeps etc to force rescheduling to occur at
different times (even inside your Lock class code) and make sure you get to
test of a true MP system. The tests should be designed so that success is
inferred from the fact no assertions failed, and the test ran to completion,
and each thread did the work assigned.

David Holmes