Re: _SC_SIGQUEUE_MAX

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

I tried to implement the unit test proposed by Christos, but needs more
clarifications.
Let me first describe my understanding of your test.
First created a thread with low priority, and let it grab the mutex. After
this step, you expect the thread with low priority will increase. Then,
created a thread with higher priority. When these two threads grab mutex at
the same time, scheduler will select
the thread with higher priority. If thread with lower priority runs first,
it indicates that the priority actually increased when grabbing the mutex.
I have 2 concerns about this unit test.
1. When there is no thread competing for a mutex, or in other words, if the
mutex is available, the thread will acquire the mutex, but never increases
priority. The priority will only increases when one thread tries to acquire
a mutex but is blocked (in which case will call mutex_lock_slow).
2. The timing of this test is hard to manage. We require these two threads
compete for the same mutex at the same time.
Any events may interrupt this, and may let us see incorrect results.
Let me know if I misunderstand your idea.

Thanks, Charles.

2016-06-22 14:53 GMT-07:00 Christos Zoulas <christos%zoulas.com@localhost>:

> On Jun 22,  1:23pm, charles.cui1984%gmail.com@localhost (Charles Cui) wrote:
> -- Subject: Re: _SC_SIGQUEUE_MAX
>
> | Any comments on the tests?
>
> Yes, I am not finished yet testing and looking. Here are some preliminary
> ones:
>
> 1. You've added more fields to sched_params. This should not be done
> lightly
>    because the system call interface is an ABI. If we want to keep them we
>    should version the syscall. There are more questions about the change.
>    Is this the right set of fields? How about exposing others like depth?
>    Should those fields be settable? Do they belong in the sched_params if
>    they are not? Even if we accept all of that they changes should be
>    documented...
> 2. On the unit test itself. It is fine what you did to check if the
> priority
>    of the thread was changed after it took the mutex lock. I would have
>    also written the test like:
>         create thread 1
>         make thread 1 low priority
>         print message with priority info
>         grab mutex.
>         print message with priority info
>         release mutex
>         print message with priority info
>
>         create thread 2
>         make thread 2 high priority
>         print message with priority info
>         attempt to grab same mutex as thread 1
>         print message with priority info
>
>         see that thread 1 runs before thread 2
>
>    instead of using thread 1 and main to make things more obvious, but it
>    is fine.
>
> I am running a system with the patches and testing it... Let's discuss
> the sched_params syscall modification... We should also look what other
> fields other OS's expose. Once we decide that you can add documentation
> and I can start committing the changes.
>
> christos
>