Uniprocessor implementation of nested mutex problem of priority inversion.

[Saurabh Gadia]

Hi,

I have created a new branch for uniprocessor solution of priority inversion
problem caused by nested mutex behavior.

link: https://github.com/saurabhgadia4/rtems/tree/nested-mutex
test case results:
https://drive.google.com/folderview?id=0B44HRKVuGCkFfnFDVmxqQzZZUzljNUg4YmVPZmEybEp2Q0NNclpvS2FvemZ4Tm5Xa19nemM&usp=sharing

Thanks,

Saurabh Gadia

On Thu, Aug 13, 2015 at 9:10 AM, Saurabh Gadia <gadia at usc.edu> wrote:

> That is how we were doing in JPF. The validate method was triggered after
> every release of mutex by any thread and we would check for all the waiting
> threads on mutex's held by the holder. And if it finds a thread with higher
> priority blocked then it would panic or give assertion failure.
>
> Thanks,
>
> Saurabh Gadia
>
> On Thu, Aug 13, 2015 at 9:08 AM, Gedare Bloom <gedare at rtems.org> wrote:
>
>> Thanks. Would it be possible for you to turn the failure cases into
>> real test failures? In other words, add some logic to detect the
>> priority inversion and abort the test?
>>
>> Gedare
>>
>> On Thu, Aug 13, 2015 at 12:05 PM, Saurabh Gadia <gadia at usc.edu> wrote:
>> > Hi,
>> >
>> > Following is the result of spsem04 test without the patch:
>> >
>> > *** 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
>> >
>> > TA02: started with priority 34
>> >
>> > TA02: priority 34, holding S1
>> >
>> > TA01: priority 34, holding S0 and now creating TA03
>> >
>> > TA03: started with priority 32
>> >
>> > TA01: priority 34 Releasing s0 (This is priority inheritance problem as
>> TA02
>> > waits on mutex held by TA01 and has higher priority than TA01. TA03 just
>> > promotes the priority TA02.)
>> >
>> > 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 ***
>> >
>> > You can see the difference in highlighted portions of both outputs.
>> >
>> > Thanks,
>> >
>> > Saurabh Gadia
>> >
>> > On Thu, Aug 13, 2015 at 8:17 AM, Saurabh Gadia <gadia at usc.edu> wrote:
>> >>
>> >> Ok. I will mail you back soon.
>> >>
>> >>
>> >> On Thursday, August 13, 2015, Gedare Bloom <gedare at rtems.org> wrote:
>> >>>
>> >>> Saurabh,
>> >>>
>> >>> Please pull from rtems.git again, create a new branch from 'master',
>> >>> and apply your changes to the branch. It's too hard to review code
>> >>> that is not all by itself on a branch.
>> >>>
>> >>> Gedare
>> >>>
>> >>> On Thu, Aug 13, 2015 at 5: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
>> >>
>> >>
>> >>
>> >> --
>> >> Thanks,
>> >>
>> >> Saurabh Gadia
>> >>
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20150813/80ee4a14/attachment-0002.html>