On Thu, Aug 13, 2015 at 7:31 PM, Cyrille Artho <cyrille.ar...@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 <ga...@usc.edu> wrote: >> >> Thanks, >> >> Saurabh Gadia >> >> ---------- Forwarded message ---------- >> From: Gedare Bloom <ged...@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 <ga...@usc.edu> >> Cc: "devel@rtems.org" <devel@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 <ga...@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 <ga...@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 <ged...@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 <ga...@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 <ga...@usc.edu> wrote: >>>>> >> >>>>> >> Ok. I will mail you back soon. >>>>> >> >>>>> >> >>>>> >> On Thursday, August 13, 2015, Gedare Bloom <ged...@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 <ga...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
