Uniprocessor implementation of nested mutex problem of priority inversion.

Thu Aug 13 23:34:46 UTC 2015

On Thu, Aug 13, 2015 at 7:31 PM, Cyrille Artho <cyrille.artho at gmail.com> wrote:
> Hi Gedard,
> The CORE_mutex_order_list in the thread priority update functions is
> needed to step down the priority in the right way upon unlocking.
> Currently these functions are only used internally.
> If you'd like a simpler interface, that list would have to be part of
> the thread data structure (Thread_Control) itself. However, then we'd
> add a field to that struct inside an #IFDEF macro.
>
> Do you think this is preferable?
>
If they're used internally, can we make them static, or do they need
to be shared across multiple subsystems. Internal functions should get
extern'ed through the "impl.h" header file variants. I need to find
time (ha!) to look more closely at this. I think the design can be
either improved, or made "cleaner" with respect to information hiding
and interface creep.

Gedare

> On Fri, Aug 14, 2015 at 8:01 AM, Saurabh Gadia <gadia at usc.edu> wrote:
>>
>> Thanks,
>>
>> Saurabh Gadia
>>
>> ---------- Forwarded message ----------
>> From: Gedare Bloom <gedare at rtems.org>
>> Date: Thu, Aug 13, 2015 at 12:51 PM
>> Subject: Re: Uniprocessor implementation of nested mutex problem of priority
>> inversion.
>> To: Saurabh Gadia <gadia at usc.edu>
>> Cc: "devel at rtems.org" <devel at rtems.org>
>>
>>
>> Saurabh,
>>
>> Remove the commit "Updated the motivation for creating the new
>> branch", don't add the .tags files, and don't add the .m4 changes that
>> are not related to your project.
>>
>> Switch to using RTEMS_CONTAINER_OF macro and remove the typeaddr one.
>>
>> coremutexseize.c : remove the modification where you deleted a blank
>> space randomly.
>>
>> threadimpl.h : follow the score naming conventions (
>> https://devel.rtems.org/wiki/Developer/Coding/NamingRules ) for the
>> new functions you introduce. Can you explain clearly why new functions
>> are needed? Also, I'm not particularly satisfied with the use of the
>> CORE_mutex_order_list type in these Thread functions. I don't see why
>> the mutex should be "baked in" to the Thread functions interface.
>> Tracking through the code, I can't even tell if it is necessary to
>> pass this argument around. Can you say whether or not you need to keep
>> this argument?
>>
>> Read the coding conventions for the style guidelines with respect to
>> block scoping. Also watch out for line lengths > 80 characters. Add
>> doxygen for new functions you introduce if they are kept around.
>>
>> For changes where the UP function invoked differs from the SMP, can
>> you please add a comment to justify the difference. I want to
>> understand why a particular code-path is followed for UP but not SMP.
>>
>> That's all for now, thanks!
>> Gedare
>>
>>
>> On Thu, Aug 13, 2015 at 1:55 PM, Saurabh Gadia <gadia at usc.edu> wrote:
>>> 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
>>>>> >>
>>>>> >
>>>>
>>>>
>>>
>>
>
>
>
> --
> Regards,
> Cyrille Artho