Uniprocessor implementation of nested mutex problem of priority inversion.

[Gedare Bloom]

Can you please print the output from spsem04 without strict-order
enabled? (Or, without your patches to fix it?)

On Thu, Aug 13, 2015 at 6:31 AM, Saurabh Gadia <gadia at usc.edu> wrote:
> Hi,
>
> To validate spsem03 test case I created a new test case by modifying
> spsem02. Below is the description of the new test case:
>
> Task: TA01 having priority 36, TA02 having priority 34, TA03 having priority
> 32.
>
> Throughout the course following actions are performed:
>
> TA01 acquires S0
> TA02 acquires S1 and then S0
> TA03 acquires S1
>
> Timeline:
>
> TA01  acquires S0 with priority 36.
> TA01 spawns TA02 having priority 32.
> TA02 takes over as it has higher priority than TA01.
> TA02 acquires S1 with priority 34.
> TA02 tries to acquire S0 but it is locked so promotes TA01 priority to 34.
> TA01 gains control and now creates TA03 having 32.
> TA03 takes over and tries to acquire S1. But it is acquired by TA02.
> TA03 promotes TA02 priority to 32. But it observe that TA02 is also waiting
> on mutex held by TA01.
> TA03 promotes TA01 priority to 32 as well. (Indirect reference case).
> TA01 get control. It releases S0 and now its priority becomes 36 so TA02
> takes over,
> TA02 acquires S0. TA02 releases S0 and S1. And its priority now becomes
> 34(real priority)
> TA03 takes over. It acquires S1. Releases S1 and suspends self.
> Now TA02 gets control. It also suspends self.
> Now TA01 gets control and exits the test.
>
> Following is the output:
> *** BEGIN OF TEST SPSEM 4 ***
> init: S0 created
> init: S1 created
> init: TA01 created with priority 36
> init: TA02 created with priority 34
> init: TA03 created with priority 32
> TA01: started with priority 36
> TA01: priority 36, holding S0  (acquires S0)
> TA02: started with priority 34  (creates TA02)
> TA02: priority 34, holding S1   (acquires S1)
> TA01: priority 34, holding S0 and now creating TA03
> TA03: started with priority 32
> TA01: priority 32 Releasing s0 (Priority of TA02 and TA01 got promoted to
> 32).
> TA02: priority 32, holding S1,S0
> TA02: priority 32 before releasing S0
> TA02: priority 32 after releasing S0
> TA02: priority 32 before releasing S1
> TA03: priority 32, holding S1
> TA03: priority 32
> TA03: suspending
> TA02: priority 34 after releasing S1
> TA02: suspending
> TA01: priority 36
> TA01: exiting
> *** END OF TEST SPSEM 4 ***
> [Inferior 1 (process 42000) exited normally]
>
>
> So this is sufficient to prove that spsem03 test passes as we just modelled
> it above.
>
>
>
>
> Thanks,
>
> Saurabh Gadia
>
> On Thu, Aug 13, 2015 at 2:28 AM, Saurabh Gadia <gadia at usc.edu> wrote:
>>
>> Hi,
>>
>> I have implemented uniprocessor model of nested mutex problem in rtems.
>> its still in basic form. I tried to multiplex it with the existing solution
>> but was finding hard time. To push ahead, I decided to have separate
>> functions for uniprocessor and SMP(kept default behavior) and with your
>> review comments will know what to do. Following is the link for the git
>> repo: https://github.com/saurabhgadia4/rtems/commits/master and its JPF
>> branch:
>> https://github.com/saurabhgadia4/lock-model/blob/uniproc-new1/rtems/Mutex.java
>>
>> I have also tested spsem01, 02, 03 test cases. Following are the links for
>> the test case results which states output before solution and after applying
>> the solution. I am still not getting whether my code is passing spsem03 test
>> or not. How can I verify that?
>>
>> Test Case Link:
>> https://drive.google.com/folderview?id=0B44HRKVuGCkFfnFDVmxqQzZZUzljNUg4YmVPZmEybEp2Q0NNclpvS2FvemZ4Tm5Xa19nemM&usp=sharing
>>
>> Thanks,
>>
>> Saurabh Gadia
>
>