Re: _SC_SIGQUEUE_MAX

[christos%astron.com@localhost (Christos Zoulas)]

In article <CA+SXE9tP1u8G7D0rVz3A7Vd75v=fDEOK8ceq0gbsPWf=7dW9Kg%mail.gmail.com@localhost>,
Charles Cui  <charles.cui1984%gmail.com@localhost> wrote:
>-=-=-=-=-=-
>
>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.

Perhaps this works:

t1 runs, grabs m1, sleeps, attempts to grab m2
t2 runs, grabs m2, attempts to grab m1

christos