Re: _SC_SIGQUEUE_MAX

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

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 <christos%astron.com@localhost>:

> 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
>
>