Hi Christos, I have spend several days of thinking how to design a unit test to prove the usefulness of the priority protect patch and here are some updates of the new unit tests. After investigating several ways of designing the tests, I realized that if we can prove low priority thread runs first after raising priority due to mutex blocking, then it indicates scheduler takes the new priority into considerations.
Here are some steps, 1. main thread sets itself to be a realtime task and launched two tasks, one has higher priority and the other has lower priority. 2. each child thread(low and high priority thread) sets its scheduler and priority. 3. each child thread did several rounds of computation, after each round it sleep 1 second. 4. the child thread with low priority will call _sched_protect to increase its protect priority. 5. We verify the thread with low priority runs first. Why does it work? For main thread, we launched thread with high priority first, this actually gives this thread some benefits of starting first. And if the thread with low priority did not call _sched_protect, the high priority thread should finish task first. After each round of computation, we call sleep, this will put the task into the sleep queue, and wake up again after the timer times out. This gives the scheduler the changes to decide which task to run. So, thread with real high priority will always block thread with real low priority. Here is the code, https://github.com/ycui1984/posixtestsuite/blob/master/patches/PRIOPROTECT_AND_GETCLOCK/0007-unit-test-for-scheduling-proof-of-priority-ceiling.patch Thanks, Charles 2016-06-27 12:45 GMT+08:00 Charles Cui <charles.cui1...@gmail.com>: > I will think about how to do it. > > > Thanks Charles > > 2016-06-25 6:32 GMT-07:00 Christos Zoulas <chris...@zoulas.com>: > >> On Jun 24, 1:56pm, charles.cui1...@gmail.com (Charles Cui) wrote: >> -- Subject: Re: _SC_SIGQUEUE_MAX >> >> | Hi Christos, >> | >> | This test generates a deadlock. t1 holds resource m1 and waits for >> m2, >> | t2 holds resource m2 and waits for m1. >> | Is this the result that you want to generate? >> >> That is correct. It should get a deadlock. And it is the wrong test. >> Perhaps we can do it with a 3rd thread like it is described here: >> >> https://en.wikipedia.org/wiki/Priority_inversion >> >> christos >> > >
