Re: _SC_SIGQUEUE_MAX

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

Yes, I can add the man pages for _sched_protect, mmap support is the missing
features at the bottom of this doc,
https://github.com/ycui1984/posixtestsuite/blob/master/errors.txt

2016-07-04 7:54 GMT+08:00 Christos Zoulas <christos%zoulas.com@localhost>:

> Can you take a stab at a man page for _sched_protect first? I think that
> realtime signal support is a bit too much for GSoC, what part of mmap are
> you suggesting to do?
>
> thanks!
>
> christos
>
> On Jul 3, 2016, at 6:33 PM, Charles Cui <charles.cui1984%gmail.com@localhost> wrote:
>
> thanks! What's the next part do you want me to focus? signal, mmap, SCHED_SPORADIC
> scheduling class or cross process synchronization?
>
>
> 2016-07-03 22:10 GMT+08:00 Christos Zoulas <christos%zoulas.com@localhost>:
>
>> 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
>>
>
> <sanitizer.log>
>
>