On Jul 1, 3:32pm, charles.cui1...@gmail.com (Charles Cui) wrote: -- Subject: Re: _SC_SIGQUEUE_MAX
| 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 | This looks great. Thanks I will commit the whole thing shortly. christos
