Yeah. I am working now on developing a validate method to point out bad and good results. And documentation seems to be super important for now because I feel that logic is correct just some semantics based on above discussion will change.<span></span><br><br>On Thursday, August 13, 2015, Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I see, it is the "list" being passed, not the mutex_control. I misread<br>
something earlier.<br>
<br>
It may be acceptable to store a pointer to this list into the<br>
Thread_Control somewhere if that will simplify the interface and not<br>
complicate the implementation by too much. But I haven't given this<br>
too much thought. Saurabh can continue to fix the other issues and we<br>
can discuss these new functions a bit more yet.<br>
<br>
Gedare<br>
<br>
On Thu, Aug 13, 2015 at 7:39 PM, Cyrille Artho <<a href="javascript:;" onclick="_e(event, 'cvml', 'cyrille.artho@gmail.com')">cyrille.artho@gmail.com</a>> wrote:<br>
> The Wait_queue maintains a queue of threads that try to obtain a lock,<br>
> but the CORE_mutex_order_list is a list of locks currently held by a<br>
> given thread. The former decides who gets the lock next (once it is<br>
> released), and the latter is needed to step down the priority of the<br>
> former lock holder on release.<br>
> One data structure contains threads, the other one locks; it is not<br>
> possible to eliminate one of them (at least not without a major<br>
> redesign of all the other code).<br>
><br>
> On Fri, Aug 14, 2015 at 8:34 AM, Saurabh Gadia <<a href="javascript:;" onclick="_e(event, 'cvml', 'gadia@usc.edu')">gadia@usc.edu</a>> wrote:<br>
>><br>
>> Thanks,<br>
>><br>
>> Saurabh Gadia<br>
>><br>
>> ---------- Forwarded message ----------<br>
>> From: Gedare Bloom <<a href="javascript:;" onclick="_e(event, 'cvml', 'gedare@rtems.org')">gedare@rtems.org</a>><br>
>> Date: Thu, Aug 13, 2015 at 4:32 PM<br>
>> Subject: Re: Uniprocessor implementation of nested mutex problem of priority<br>
>> inversion.<br>
>> To: Saurabh Gadia <<a href="javascript:;" onclick="_e(event, 'cvml', 'gadia@usc.edu')">gadia@usc.edu</a>><br>
>> Cc: "<a href="javascript:;" onclick="_e(event, 'cvml', 'devel@rtems.org')">devel@rtems.org</a>" <<a href="javascript:;" onclick="_e(event, 'cvml', 'devel@rtems.org')">devel@rtems.org</a>><br>
>><br>
>><br>
>> On Thu, Aug 13, 2015 at 6:55 PM, Saurabh Gadia <<a href="javascript:;" onclick="_e(event, 'cvml', 'gadia@usc.edu')">gadia@usc.edu</a>> wrote:<br>
>>> How can we get mutex->queue.priority_before data structure without having<br>
>>> the mutex structure. We need that to change the priority_before for every<br>
>>> acquired mutex by a thread to ensure that there is proper stepdown of<br>
>>> priority. We just need to have mutex to get the start point of the<br>
>>> chain_control and then we traverse upto the head of the chain to<br>
>>> manipulate<br>
>>> the priority_before if required<br>
>><br>
>> From what I see, you're approximately using container_of(holder,<br>
>> queue) to get the thread queue, from that you can get the Wait_queue<br>
>> in the mutex_control, and find the priority_before. So you don't need<br>
>> to pass the pointer to the mutex_control if you can recover it from<br>
>> the holder thread_control, right?<br>
>><br>
>> Just add some conditional code (based on RTEMS_SMP and/or<br>
>> STRICT_ORDER) in the existing functions that follows the pointer from<br>
>> the thread to the threadq to the mutex to find the priority_before.<br>
>> Unless I missed something.<br>
>><br>
>> Gedare<br>
>><br>
>>> Thanks,<br>
>>><br>
>>> Saurabh Gadia<br>
>>><br>
>>> On Thu, Aug 13, 2015 at 12:51 PM, Gedare Bloom <<a href="javascript:;" onclick="_e(event, 'cvml', 'gedare@rtems.org')">gedare@rtems.org</a>> wrote:<br>
>>>><br>
>>>> 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" 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>
>>>> Gedare<br>
>><br>
>>>><br>
>>>><br>
>>>> On Thu, Aug 13, 2015 at 1:55 PM, Saurabh Gadia <<a href="javascript:;" onclick="_e(event, 'cvml', 'gadia@usc.edu')">gadia@usc.edu</a>> wrote:<br>
>>>> > Hi,<br>
>>>> ><br>
>>>> > I have created a new branch for uniprocessor solution of priority<br>
>>>> > inversion<br>
>>>> > problem caused by nested mutex behavior.<br>
>>>> ><br>
>>>> > link: <a href="https://github.com/saurabhgadia4/rtems/tree/nested-mutex" target="_blank">https://github.com/saurabhgadia4/rtems/tree/nested-mutex</a><br>
>>>> > test case results:<br>
>>>> ><br>
>>>> ><br>
>>>> > <a href="https://drive.google.com/folderview?id=0B44HRKVuGCkFfnFDVmxqQzZZUzljNUg4YmVPZmEybEp2Q0NNclpvS2FvemZ4Tm5Xa19nemM&usp=sharing" 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="javascript:;" onclick="_e(event, 'cvml', 'gadia@usc.edu')">gadia@usc.edu</a>> wrote:<br>
>>>> >><br>
>>>> >> That is how we were doing in JPF. The validate method was triggered<br>
>>>> >> after<br>
>>>> >> every release of mutex by any thread and we would check for all the<br>
>>>> >> waiting<br>
>>>> >> threads on mutex's held by the holder. And if it finds a thread with<br>
>>>> >> 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="javascript:;" onclick="_e(event, 'cvml', 'gedare@rtems.org')">gedare@rtems.org</a>><br>
>>>> >> 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="javascript:;" onclick="_e(event, 'cvml', 'gadia@usc.edu')">gadia@usc.edu</a>><br>
>>>> >>> 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<br>
>>>> >>> > problem<br>
>>>> >>> > 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="javascript:;" onclick="_e(event, 'cvml', 'gadia@usc.edu')">gadia@usc.edu</a>><br>
>>>> >>> > wrote:<br>
>>>> >>> >><br>
>>>> >>> >> Ok. I will mail you back soon.<br>
>>>> >>> >><br>
>>>> >>> >><br>
>>>> >>> >> On Thursday, August 13, 2015, Gedare Bloom <<a href="javascript:;" onclick="_e(event, 'cvml', 'gedare@rtems.org')">gedare@rtems.org</a>><br>
>>>> >>> >> wrote:<br>
>>>> >>> >>><br>
>>>> >>> >>> Saurabh,<br>
>>>> >>> >>><br>
>>>> >>> >>> Please pull from rtems.git again, create a new branch from<br>
>>>> >>> >>> 'master',<br>
>>>> >>> >>> and apply your changes to the branch. It's too hard to review<br>
>>>> >>> >>> 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="javascript:;" onclick="_e(event, 'cvml', 'gadia@usc.edu')">gadia@usc.edu</a>><br>
>>>> >>> >>> wrote:<br>
>>>> >>> >>> > Hi,<br>
>>>> >>> >>> ><br>
>>>> >>> >>> > I have implemented uniprocessor model of nested mutex problem<br>
>>>> >>> >>> > 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<br>
>>>> >>> >>> > 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<br>
>>>> >>> >>> > git<br>
>>>> >>> >>> > repo:<br>
>>>> >>> >>> > <a href="https://github.com/saurabhgadia4/rtems/commits/master" target="_blank">https://github.com/saurabhgadia4/rtems/commits/master</a> and its<br>
>>>> >>> >>> > JPF<br>
>>>> >>> >>> > branch:<br>
>>>> >>> >>> ><br>
>>>> >>> >>> ><br>
>>>> >>> >>> ><br>
>>>> >>> >>> ><br>
>>>> >>> >>> > <a href="https://github.com/saurabhgadia4/lock-model/blob/uniproc-new1/rtems/Mutex.java" 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<br>
>>>> >>> >>> > the<br>
>>>> >>> >>> > links<br>
>>>> >>> >>> > for<br>
>>>> >>> >>> > the test case results which states output before solution and<br>
>>>> >>> >>> > 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>
>>>> >>> >>> ><br>
>>>> >>> >>> ><br>
>>>> >>> >>> > <a href="https://drive.google.com/folderview?id=0B44HRKVuGCkFfnFDVmxqQzZZUzljNUg4YmVPZmEybEp2Q0NNclpvS2FvemZ4Tm5Xa19nemM&usp=sharing" 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>
>>><br>
>>><br>
>><br>
><br>
><br>
><br>
> --<br>
> Regards,<br>
> Cyrille Artho<br>
</blockquote><br><br>-- <br><div dir="ltr">Thanks,<div><br></div><div>Saurabh Gadia</div></div><br>