[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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
>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
Main Index |
Thread Index |