<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>Hi Sebastian,<br></div><br></div>Sorry for late reply. I was out of town and could not reply. I am bit confused with above description which I need to get clarified:<br><br></div>1. replaced LIFO with sorted list:  I don't change the mutex order to make the list sorted. Instead I promote the priorities so that we don't need to change position of mutex in the chain and the list without any swapping of mutex in chain becomes sorted and valid.<br><br><br></div>2. I was confused with spsem03 test cases. So I created spsem04 test case which demonstrates that our implementation supports horizontal implementation. It has the same scenario of test case 3 but now we can say that horizontal nesting works correctly. you can find all description about this test cases on link below.<br><br><a href="https://docs.google.com/document/d/1RM427RKSoyrZrchEcDIx4etmtWqrFArzRRLWqcU8RK0/edit?usp=sharing">https://docs.google.com/document/d/1RM427RKSoyrZrchEcDIx4etmtWqrFArzRRLWqcU8RK0/edit?usp=sharing</a><br><br></div>3. Your mentioned example is definitely supported by the our implementation.<br><br></div>I also need clarification on ticket 2412:<br><br></div>1. Is there something wrong with problem description?<br></div>    it says - "The allocator mutex is already owned, so the priority of the low 
priority thread is raised to the priority of the high priority thread.  
The memory allocation completes and the allocator mutex is released, 
since the low priority thread still owns the file system instance mutex 
it continues to execute with the high priority (the high priority thread
 is not scheduled)"<br></div><br></div>Instead --> after releasing lock over allocator the low priority threads priority will no longer be high as there is restoration of priority of on mutex release. This is the behavior with our implementation. So low priority thread will again be restored at its original priority after releasing allocator lock.<br><div><br><b>I am not able to get what do we have to do in this ticket like what is the problem we are trying to solve(objective, current behavior)<br><br></b></div><div>2. Our implementation is only for strict order mutex behavior and will not work for unordered mutex operations. We will need complete different implementation for unordered mutex operation.<br><br></div><div>3. Our SMP implementation has recursive mutex acquisition behavior for supporting horizontal nesting? Will it be fine with RTEMS?<br><br></div><div>note: <b>Cyrille</b> please mention any other doubts if I have missed any.<br></div></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 Sun, Sep 6, 2015 at 11:04 PM, Sebastian Huber <span dir="ltr"><<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Saurabh,<span class=""><br>
<br>
On 05/09/15 01:52, Saurabh Gadia wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is the patch for solving priority inversion problem for uniprocessor architecture. It works correctly for all test cases on master. For 4.11 the patch get applied cleanly but the branch does not compile because of some rbtree error(unrelated to project). Github 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>
</blockquote>
<br></span>
I reviewed your patch. Basically you replaced the LIFO list of priorities with a sorted list? Does it work with timeouts and external priority changes (e.g. task A blocks on a mutex owned by O, another task B raises the priority of A, will this raise the priority of O?)<br>
<br>
Since all tests pass, test sptests/spsem03 passes, which shows that your implementation doesn't support horizontal nesting.<br>
<br>
There is no deadlock detection.<br>
<br>
Please have a look at:<br>
<br>
<a href="https://devel.rtems.org/ticket/2412" rel="noreferrer" target="_blank">https://devel.rtems.org/ticket/2412</a><br>
<br>
I think the suggested implementation would even work on SMP systems quite well.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone   : <a href="tel:%2B49%2089%20189%2047%2041-16" value="+4989189474116" target="_blank">+49 89 189 47 41-16</a><br>
Fax     : <a href="tel:%2B49%2089%20189%2047%2041-09" value="+4989189474109" target="_blank">+49 89 189 47 41-09</a><br>
E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
PGP     : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
<br>
</font></span></blockquote></div><br></div>