From da68278385b02505d32cbaa9b623d689ed68cbcf Mon Sep 17 00:00:00 2001 From: Giovanni Di Sirio Date: Tue, 29 Mar 2016 15:33:45 +0000 Subject: git-svn-id: svn://svn.code.sf.net/p/chibios/svn/trunk@9180 35acf78f-673a-0410-8e92-d51de3d6d3f4 --- test/rt/configuration.xml | 515 ++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 500 insertions(+), 15 deletions(-) (limited to 'test/rt/configuration.xml') diff --git a/test/rt/configuration.xml b/test/rt/configuration.xml index bd6bd6525..32a6bf141 100644 --- a/test/rt/configuration.xml +++ b/test/rt/configuration.xml @@ -1205,7 +1205,7 @@ test_assert(sem1.cnt == 0, "counter not zero");]]> - @@ -1218,7 +1218,7 @@ msg_t msg;]]> - @@ -1242,7 +1242,7 @@ test_assert_lock(chBSemGetStateI(&bsem) == true, "not taken");]]> - @@ -1254,8 +1254,8 @@ test_assert_lock(chBSemGetStateI(&bsem) == true, "not taken");]]> - @@ -1267,8 +1267,8 @@ test_assert(msg == MSG_OK, "unexpected message");]]> - @@ -1280,8 +1280,8 @@ test_assert_lock(chSemGetCounterI(&bsem.sem) == 1, "unexpected counter");]]> - @@ -1303,13 +1303,498 @@ test_assert_lock(chSemGetCounterI(&bsem.sem) == 1, "unexpected counter");]]>CH_CFG_USE_MUTEXES - + - + + + + Priority enqueuing test. + + + Five threads, with increasing priority, are enqueued on a locked mutex then the mutex is unlocked. The test expects the threads to perform their operations in increasing priority order regardless of the initial order. + + + + + + + + + + + + + + + + + + + Getting the initial priority. + + + + + + + + + + + Locking the mutex. + + + + + + + + + + + Five threads are created that try to lock and unlock the mutex then terminate. The threads are created in ascending priority order. + + + + + + + + + + + Unlocking the mutex, the threads will wakeup in priority order because the mutext queue is an ordered one. + + + + + + + + + + + + + Priority inheritance, simple case. + + + Three threads are involved in the classic priority inversion scenario, a medium priority thread tries to starve an high priority thread by blocking a low priority thread into a mutex lock zone. The test expects the threads to reach their goal in increasing priority order by rearranging their priorities in order to avoid the priority inversion trap. + + + + + + + + + + + + + + + + + + + Getting the system time for test duration measurement. + + + + + + + + + + + The three contenders threads are created and let run atomically, the goals sequence is tested, the threads must complete in priority order. + + + + + + + + + + + Testing that all threads completed within the specified time windows (100mS...100mS+ALLOWED_DELAY). + + + + + + + + + + + + + Priority inheritance, complex case. + + + Five threads are involved in the complex priority inversion scenario, the priority inheritance algorithm is tested for depths greater than one. The test expects the threads to perform their operations in increasing priority order by rearranging their priorities in order to avoid the priority inversion trap. + + + + + + + + + + + + + + + + + + + Getting the system time for test duration measurement. + + + + + + + + + + + The five contenders threads are created and let run atomically, the goals sequence is tested, the threads must complete in priority order. + + + + + + + + + + + Testing that all threads completed within the specified time windows (110mS...110mS+ALLOWED_DELAY). + + + + + + + + + + + + + Priority return verification. + + + Two threads are spawned that try to lock the mutexes already locked by the tester thread with precise timing. The test expects that the priority changes caused by the priority inheritance algorithm happen at the right moment and with the right values.<br> +Thread A performs wait(50), lock(m1), unlock(m1), exit. Thread B performs wait(150), lock(m2), unlock(m2), exit. + + + + + + + + + + + + + + + + + + + Getting current thread priority P(0) and assigning to the threads A and B priorities +1 and +2. + + + + + + + + + + + Spawning threads A and B at priorities P(A) and P(B). + + + + + + + + + + + Locking the mutex M1 before thread A has a chance to lock it. The priority must not change because A has not yet reached chMtxLock(M1). the mutex is not locked. + + + + + + + + + + + Waiting 100mS, this makes thread A reach chMtxLock(M1) and get the mutex. This must boost the priority of the current thread at the same level of thread A. + + + + + + + + + + + Locking the mutex M2 before thread B has a chance to lock it. The priority must not change because B has not yet reached chMtxLock(M2). the mutex is not locked. + + + + + + + + + + + Waiting 100mS, this makes thread B reach chMtxLock(M2) and get the mutex. This must boost the priority of the current thread at the same level of thread B. + + + + + + + + + + + Unlocking M2, the priority should fall back to P(A). + + + + + + + + + + + Unlocking M1, the priority should fall back to P(0). + + + + + + + + + + + -- cgit v1.2.3