Re: _SC_SIGQUEUE_MAX

[Charles Cui <charles.cui1984%gmail.com@localhost>]

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.cui1984%gmail.com@localhost>:

> I will think about how to do it.
>
>
> Thanks Charles
>
> 2016-06-25 6:32 GMT-07:00 Christos Zoulas <christos%zoulas.com@localhost>:
>
>> On Jun 24,  1:56pm, charles.cui1984%gmail.com@localhost (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
>>
>
>