Tests SMP-specific thread queue behaviour.
More...
|
|
| T_TEST_CASE_FIXTURE (ScoreTqValSmp, &ScoreTqValSmp_Fixture) |
| |
Tests SMP-specific thread queue behaviour.
This test case performs the following actions:
- Create two or three worker threads and a mutex. Use the mutex and the worker to do a thread priority change in parallel with a thread queue extraction.
- Create a mutex and let the runner obtain it.
- Create and start worker A on a second processor. mutex. Let it wait on the barrier.
- If there are more than two processors, then create and start also worker C. Let it wait on the barrier.
- Create and start worker B. Let it try to obtain the mutex which is owned by the runner. Delete worker B to extract it from the thread queue. Wrap the thread queue extract operation to do a parallel thread priority change carried out by worker A (and maybe C).
- Clean up all used resources.
- Build a cyclic dependency graph using several worker threads and mutexes. Use the mutexes and the worker to construct a thread queue deadlock which is detected on one processor while it uses thread queue links inserted by another processor. The runner thread controls the test scenario via the two thread queue locks. This is an important test scenario which shows why the thread queue implementation is a bit more complicated in SMP configurations.
- Let worker D wait for mutex A. Let worker C wait for mutex D. Let worker B wait for mutex C.
- Let worker A attempt to obtain mutex B. Let worker A wait on the lock of mutex C. Worker A will insert two thread queue links.
- Let worker E try to obtain mutex D. Worker E will add a thread queue link which is later used by worker A to detect the deadlock.
- Let worker A continue the obtain sequence. It will detect a deadlock.
- Clean up all used resources.
1.9.6