Hi Christos, This test generates a deadlock. t1 holds resource m1 and waits for m2, t2 holds resource m2 and waits for m1. Is this the result that you want to generate?
2016-06-24 6:05 GMT-07:00 Christos Zoulas <chris...@astron.com>: > 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 > >
