[concurrency-interest] unit testing concurrency code.
josh at bloch.us
Thu Nov 24 20:20:01 EST 2005
Nor can you reliably determine that a program works merely by proving
it correct. You can only prove correctness with respect to some
model, which may itself be flawed. Also your proof may be faulty.
Some combination of testing and proof works best. Also it's important
to show your program to other experts. Two (or more) heads are better
On 9/20/05, Rick Beton <richard.beton at roke.co.uk> wrote:
> Brian Goetz wrote:
> > Testing concurrent code is an extension of testing regular code.
> > First, you must have good tests for functionality, and be able to test
> > as many of your classes invariants as possible. The trick is then
> > trying to generate as many random interleavings of operations as you
> > can, without the test framework introducing timing artifacts that will
> > prevent certain interleavings from being tested.
> Surely this overlooks something: there are four kinds of dynamic failure
> (deadlock, livelock, starvation and race) that you cannot prove are
> absent simply by testing alone. You can prove they are *present* if
> your testing finds them, but you can't prove they are *absent*.
> This is quite important if you are writing concurrency classes for other
> people to use. You cannot write tests with enough coverage to handle
> every end-user's use cases. Simply covering a certain subset of dynamic
> behaviour and then passing such classes as "tested" may be a bit too
> optimistic and misleading.
> I'd like to draw your attention to Peter Welch's posting ("CSP, the
> pi-calculus and CPA-2005") and the work he and others have done using
> CSP as the basis for establishing thread reliability (establishing the
> absence of deadlock, livelock, starvation and race). My own experience
> is limited to being a JCSP user, rather than having much theoretical
> skill. There are some straightforward design rules that guarantee
> deadlock freedom for example. This makes JCSP a simple strategy to
> apply to practical usage.
> Visit our website at www.roke.co.uk
> Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK.
> The information contained in this e-mail and any attachments is proprietary to
> Roke Manor Research Ltd and must not be passed to any third party without
> permission. This communication is for information only and shall not create or
> change any contractual relationship.
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest