How can we get mutex->queue.priority_before data structure without having the mutex structure. We need that to change the priority_before for every acquired mutex by a thread to ensure that there is proper stepdown of priority. We just need to have mutex to get the start point of the chain_control and then we traverse upto the head of the chain to manipulate the priority_before if required.
Thanks, Saurabh Gadia On Thu, Aug 13, 2015 at 12:51 PM, Gedare Bloom <ged...@rtems.org> wrote: > 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 > >>> >> > >>> > > >> > >> > > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
