<div dir="ltr">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.<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Thanks,<div><br></div><div>Saurabh Gadia</div></div></div></div>
<br><div class="gmail_quote">On Thu, Aug 13, 2015 at 12:51 PM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Saurabh,<br>
<br>
Remove the commit "Updated the motivation for creating the new<br>
branch", don't add the .tags files, and don't add the .m4 changes that<br>
are not related to your project.<br>
<br>
Switch to using RTEMS_CONTAINER_OF macro and remove the typeaddr one.<br>
<br>
coremutexseize.c : remove the modification where you deleted a blank<br>
space randomly.<br>
<br>
threadimpl.h : follow the score naming conventions (<br>
<a href="https://devel.rtems.org/wiki/Developer/Coding/NamingRules" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/Developer/Coding/NamingRules</a> ) for the<br>
new functions you introduce. Can you explain clearly why new functions<br>
are needed? Also, I'm not particularly satisfied with the use of the<br>
CORE_mutex_order_list type in these Thread functions. I don't see why<br>
the mutex should be "baked in" to the Thread functions interface.<br>
Tracking through the code, I can't even tell if it is necessary to<br>
pass this argument around. Can you say whether or not you need to keep<br>
this argument?<br>
<br>
Read the coding conventions for the style guidelines with respect to<br>
block scoping. Also watch out for line lengths > 80 characters. Add<br>
doxygen for new functions you introduce if they are kept around.<br>
<br>
For changes where the UP function invoked differs from the SMP, can<br>
you please add a comment to justify the difference. I want to<br>
understand why a particular code-path is followed for UP but not SMP.<br>
<br>
That's all for now, thanks!<br>
<span class="HOEnZb"><font color="#888888">Gedare<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Thu, Aug 13, 2015 at 1:55 PM, Saurabh Gadia <<a href="mailto:gadia@usc.edu">gadia@usc.edu</a>> wrote:<br>
> Hi,<br>
><br>
> I have created a new branch for uniprocessor solution of priority inversion<br>
> problem caused by nested mutex behavior.<br>
><br>
> link: <a href="https://github.com/saurabhgadia4/rtems/tree/nested-mutex" rel="noreferrer" target="_blank">https://github.com/saurabhgadia4/rtems/tree/nested-mutex</a><br>
> test case results:<br>
> <a href="https://drive.google.com/folderview?id=0B44HRKVuGCkFfnFDVmxqQzZZUzljNUg4YmVPZmEybEp2Q0NNclpvS2FvemZ4Tm5Xa19nemM&usp=sharing" rel="noreferrer" target="_blank">https://drive.google.com/folderview?id=0B44HRKVuGCkFfnFDVmxqQzZZUzljNUg4YmVPZmEybEp2Q0NNclpvS2FvemZ4Tm5Xa19nemM&usp=sharing</a><br>
><br>
> Thanks,<br>
><br>
> Saurabh Gadia<br>
><br>
> On Thu, Aug 13, 2015 at 9:10 AM, Saurabh Gadia <<a href="mailto:gadia@usc.edu">gadia@usc.edu</a>> wrote:<br>
>><br>
>> That is how we were doing in JPF. The validate method was triggered after<br>
>> every release of mutex by any thread and we would check for all the waiting<br>
>> threads on mutex's held by the holder. And if it finds a thread with higher<br>
>> priority blocked then it would panic or give assertion failure.<br>
>><br>
>> Thanks,<br>
>><br>
>> Saurabh Gadia<br>
>><br>
>> On Thu, Aug 13, 2015 at 9:08 AM, Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br>
>>><br>
>>> Thanks. Would it be possible for you to turn the failure cases into<br>
>>> real test failures? In other words, add some logic to detect the<br>
>>> priority inversion and abort the test?<br>
>>><br>
>>> Gedare<br>
>>><br>
>>> On Thu, Aug 13, 2015 at 12:05 PM, Saurabh Gadia <<a href="mailto:gadia@usc.edu">gadia@usc.edu</a>> wrote:<br>
>>> > Hi,<br>
>>> ><br>
>>> > Following is the result of spsem04 test without the patch:<br>
>>> ><br>
>>> > *** BEGIN OF TEST SPSEM 4 ***<br>
>>> ><br>
>>> > init: S0 created<br>
>>> ><br>
>>> > init: S1 created<br>
>>> ><br>
>>> > init: TA01 created with priority 36<br>
>>> ><br>
>>> > init: TA02 created with priority 34<br>
>>> ><br>
>>> > init: TA03 created with priority 32<br>
>>> ><br>
>>> > TA01: started with priority 36<br>
>>> ><br>
>>> > TA01: priority 36, holding S0<br>
>>> ><br>
>>> > TA02: started with priority 34<br>
>>> ><br>
>>> > TA02: priority 34, holding S1<br>
>>> ><br>
>>> > TA01: priority 34, holding S0 and now creating TA03<br>
>>> ><br>
>>> > TA03: started with priority 32<br>
>>> ><br>
>>> > TA01: priority 34 Releasing s0 (This is priority inheritance problem as<br>
>>> > TA02<br>
>>> > waits on mutex held by TA01 and has higher priority than TA01. TA03<br>
>>> > just<br>
>>> > promotes the priority TA02.)<br>
>>> ><br>
>>> > TA02: priority 32, holding S1,S0<br>
>>> ><br>
>>> > TA02: priority 32 before releasing S0<br>
>>> ><br>
>>> > TA02: priority 32 after releasing S0<br>
>>> ><br>
>>> > TA02: priority 32 before releasing S1<br>
>>> ><br>
>>> > TA03: priority 32, holding S1<br>
>>> ><br>
>>> > TA03: priority 32<br>
>>> ><br>
>>> > TA03: suspending<br>
>>> ><br>
>>> > TA02: priority 34 after releasing S1<br>
>>> ><br>
>>> > TA02: suspending<br>
>>> ><br>
>>> > TA01: priority 36<br>
>>> ><br>
>>> > TA01: exiting<br>
>>> ><br>
>>> > *** END OF TEST SPSEM 4 ***<br>
>>> ><br>
>>> > You can see the difference in highlighted portions of both outputs.<br>
>>> ><br>
>>> > Thanks,<br>
>>> ><br>
>>> > Saurabh Gadia<br>
>>> ><br>
>>> > On Thu, Aug 13, 2015 at 8:17 AM, Saurabh Gadia <<a href="mailto:gadia@usc.edu">gadia@usc.edu</a>> wrote:<br>
>>> >><br>
>>> >> Ok. I will mail you back soon.<br>
>>> >><br>
>>> >><br>
>>> >> On Thursday, August 13, 2015, Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br>
>>> >>><br>
>>> >>> Saurabh,<br>
>>> >>><br>
>>> >>> Please pull from rtems.git again, create a new branch from 'master',<br>
>>> >>> and apply your changes to the branch. It's too hard to review code<br>
>>> >>> that is not all by itself on a branch.<br>
>>> >>><br>
>>> >>> Gedare<br>
>>> >>><br>
>>> >>> On Thu, Aug 13, 2015 at 5:28 AM, Saurabh Gadia <<a href="mailto:gadia@usc.edu">gadia@usc.edu</a>> wrote:<br>
>>> >>> > Hi,<br>
>>> >>> ><br>
>>> >>> > I have implemented uniprocessor model of nested mutex problem in<br>
>>> >>> > rtems.<br>
>>> >>> > its<br>
>>> >>> > still in basic form. I tried to multiplex it with the existing<br>
>>> >>> > solution<br>
>>> >>> > but<br>
>>> >>> > was finding hard time. To push ahead, I decided to have separate<br>
>>> >>> > functions<br>
>>> >>> > for uniprocessor and SMP(kept default behavior) and with your<br>
>>> >>> > review<br>
>>> >>> > comments will know what to do. Following is the link for the git<br>
>>> >>> > repo:<br>
>>> >>> > <a href="https://github.com/saurabhgadia4/rtems/commits/master" rel="noreferrer" target="_blank">https://github.com/saurabhgadia4/rtems/commits/master</a> and its JPF<br>
>>> >>> > branch:<br>
>>> >>> ><br>
>>> >>> ><br>
>>> >>> > <a href="https://github.com/saurabhgadia4/lock-model/blob/uniproc-new1/rtems/Mutex.java" rel="noreferrer" target="_blank">https://github.com/saurabhgadia4/lock-model/blob/uniproc-new1/rtems/Mutex.java</a><br>
>>> >>> ><br>
>>> >>> > I have also tested spsem01, 02, 03 test cases. Following are the<br>
>>> >>> > links<br>
>>> >>> > for<br>
>>> >>> > the test case results which states output before solution and after<br>
>>> >>> > applying<br>
>>> >>> > the solution. I am still not getting whether my code is passing<br>
>>> >>> > spsem03<br>
>>> >>> > test<br>
>>> >>> > or not. How can I verify that?<br>
>>> >>> ><br>
>>> >>> > Test Case Link:<br>
>>> >>> ><br>
>>> >>> ><br>
>>> >>> > <a href="https://drive.google.com/folderview?id=0B44HRKVuGCkFfnFDVmxqQzZZUzljNUg4YmVPZmEybEp2Q0NNclpvS2FvemZ4Tm5Xa19nemM&usp=sharing" rel="noreferrer" target="_blank">https://drive.google.com/folderview?id=0B44HRKVuGCkFfnFDVmxqQzZZUzljNUg4YmVPZmEybEp2Q0NNclpvS2FvemZ4Tm5Xa19nemM&usp=sharing</a><br>
>>> >>> ><br>
>>> >>> > Thanks,<br>
>>> >>> ><br>
>>> >>> > Saurabh Gadia<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> --<br>
>>> >> Thanks,<br>
>>> >><br>
>>> >> Saurabh Gadia<br>
>>> >><br>
>>> ><br>
>><br>
>><br>
><br>
</div></div></blockquote></div><br></div>