Testing approaches for Concurrency Testing
Defect-based
Will focus on specific types of concurrency bugs
Long-duration / Random Testing
Rely on the fact that concurrency errors occur very rarely
Model-based Testing
Use MBT tools that support modeling of concurrent behavior
Manual Delays
Use delays (e.g. Thread.sleep()) to enforce specific schedules
Synchronization mechanisms
Blocking -> Starvation, Suspension
Non-Blocking -> Atomicity violation
Non-Deadlock Bugs
Livelock
Starvation
Suspension
Order Violation
Priority Inversion
Atomcity Violation
Why is concurrency testing hard?
Intermittent/nondeterministic failures that only occur rarely
Non-deterministic behaviour
different outcome for same test
hard to reproduce failures
hard to analyze
Correcting concurrency bugs often requires redesign instead of simple code changes
Conditions for Deadlock
Mutual Exklusion: shared resource
Hold and Wait: process holding a resource and process waiting for it
No Preemption: resource can only be released by process holding it
Circular Wait: set of processes {P1, P2, …, Pn} such that P1 waits for P2, …, Pn waits for P1
Thread repeatedly obtains resource but never completes execution before losing it
thread ready to execute, but delayed because other threads hold necessery resource
thread waiting too long before it can access shared resource
fault caused by nondeterministic ordering of multiple interleaved operations
-> Race Condition - special form: shared resources not protected from simultaneous access
higher priority operation of one thread forced to wait for execution of lower priority of another thread
Atomicity Violation
execution of one thread interrupts execution of another thread
Last changeda year ago