<div dir="ltr"><div><div><div><div>Hi,<br><br></div>I have implemented the validate method. following are the links for it:<br></div>github: <a href="https://github.com/saurabhgadia4/rtems/tree/nested-mutex">https://github.com/saurabhgadia4/rtems/tree/nested-mutex</a><br></div>commit: <a href="https://github.com/saurabhgadia4/rtems/commit/e7f0f169c056076c46ef5ea17b0c38efe33fe576">https://github.com/saurabhgadia4/rtems/commit/e7f0f169c056076c46ef5ea17b0c38efe33fe576</a><br><br></div>I am waiting on the decision of how to integrate call to this _Thread_Validate_Priority.<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 Fri, Aug 14, 2015 at 10:06 AM, Saurabh Gadia <span dir="ltr"><<a href="mailto:gadia@usc.edu" target="_blank">gadia@usc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>And in respect of efficiency, we have to traverse through all the mutex held my the thread and do the checking. There is no other way to confirm that priority inversion has occurred or not. One way we can do is have default argument variable for core_mutex_surrender but then there is change in API call semantics. So kind of stuck between which way to take. <br><br></div>One way is that we can do lazy evaluation. following should be the calling pair:<br>task1()<br>{<br>...<br>...<br>rtems_semaphore_release()<br></div>validate()<br>}<br></div>these pairs should be intact so even if the task1 thread gets preempted after calling rtems_semaphore_release(), then other thread will get control of processor. When this task1 thread get the control back then next call it will do is validate() which is no harm to us as only task 1 thread can release rest of its resources of we have owner release binding. But there can be one problem that is Till the task 1 thread get the control back its priority may be promoted by other task thread. So it won't be 100% accurate validate test. <br><br></div>Main problem still exists is: For uniprocessor(for this project scope) implementation how can we make sure that only after validate method task1 can be preempted ( To acheive this behavior I guess we will need to make change to core_mutex_surrender).<br></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr">Thanks,<div><br></div><div>Saurabh Gadia</div></div></div></div><div><div class="h5">
<br><div class="gmail_quote">On Fri, Aug 14, 2015 at 9:43 AM, Saurabh Gadia <span dir="ltr"><<a href="mailto:gadia@usc.edu" target="_blank">gadia@usc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>When a thread releases a semaphore/mutex we call this validate method to make sure that there does not exists any priority inversion. Following is the course of action that needs to be performed:<br><br></div><div>1. Validate method needs to be called within mutex_surrender method because after releasing a mutex a new holder thread can get scheduled and then we can't call validate method. We need to do call validate before we enable interrupts in uniprocessor or dispatching of threads. <br><br></div><div>2. Functioning of validate method: input param -  executing thread (thread which releases the mutex)<br><br></div><div>2.a) Go through the list of Mutex Chain i.e( Chain_Control lock_mutex;) in TCB. <br>2.b) Extract mutex from the chain node linked list. This gives us (the_mutex->queue.lock_queue) from which we will extract mutex by using CONTAINER_OF() method.<br><br></div><div>2.c) Now access the thread wait queue of this mutex i.e(the_mutex->Wait_queue) to get the information about the first waiting thread in this waitqueue by calling _Thread_queue_First_locked(&the_mutex->Wait_queue)<br><br></div><div>2.d) Now check whether assert(releasingThread.current_priority<=first_locked_thread.currentPriority). If assertion fails then there is priority inversion problem and we can break out of loop and return error status.<br><br></div><div>2.e) Repeat from 2.a till all acquired resources are visited present in Chain_Control of releasing thread.<br><br></div><div>So I am sceptical about how can I include this validate method in the _CORE_mutex_Surrender(). We can have it as a separate call from user level but then we need to make sure that the thread dispatch mechanism is disabled. If not then whether including this validate method in _CORE_mutex_Surrender for only strict_order_mutex and Priority inheritance attribute is feasible or not.<br><br></div><div>Please guide me on this.<br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr">Thanks,<div><br></div><div>Saurabh Gadia</div></div></div></div><div><div>
<br><div class="gmail_quote">On Thu, Aug 13, 2015 at 9:10 AM, Saurabh Gadia <span dir="ltr"><<a href="mailto:gadia@usc.edu" target="_blank">gadia@usc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<br></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr">Thanks,<div><br></div><div>Saurabh Gadia</div></div></div></div><div><div>
<br><div class="gmail_quote">On Thu, Aug 13, 2015 at 9:08 AM, 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">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>
<span><font color="#888888"><br>
Gedare<br>
</font></span><div><div><br>
On Thu, Aug 13, 2015 at 12:05 PM, Saurabh Gadia <<a href="mailto:gadia@usc.edu" target="_blank">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 TA02<br>
> waits on mutex held by TA01 and has higher priority than TA01. TA03 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" target="_blank">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" target="_blank">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" target="_blank">gadia@usc.edu</a>> wrote:<br>
>>> > Hi,<br>
>>> ><br>
>>> > I have implemented uniprocessor model of nested mutex problem in rtems.<br>
>>> > its<br>
>>> > still in basic form. I tried to multiplex it with the existing 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 review<br>
>>> > comments will know what to do. Following is the link for the git 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>
>>> > <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 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 spsem03<br>
>>> > test<br>
>>> > or not. How can I verify that?<br>
>>> ><br>
>>> > Test Case Link:<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>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div>