Re: _SC_SIGQUEUE_MAX

[christos%zoulas.com@localhost (Christos Zoulas)]

On Jul 1,  3:32pm, charles.cui1984%gmail.com@localhost (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