Uniprocessor implementation of nested mutex problem of priority inversion.

[Saurabh Gadia]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20150813/cd962fe0/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: init.c
Type: text/x-csrc
Size: 6034 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20150813/cd962fe0/attachment-0002.bin>