[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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
can prove low priority thread runs first after raising priority due to
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
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
Here is the code,
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
>> | 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:
Main Index |
Thread Index |