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.cui1...@gmail.com> 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 <chris...@zoulas.com>: > >> 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 > > <sanitizer.log>
