In article <CA+SXE9tP1u8G7D0rVz3A7Vd75v=fDEOK8ceq0gbsPWf=7dw...@mail.gmail.com>, Charles Cui <charles.cui1...@gmail.com> 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
