I will try to model this test case environment soon and get back to you. <div>@gedare - you are absolutely correct about the description of project<span></span><br><br>On Friday, June 26, 2015, Gedare Bloom <<a href="mailto:gedare@gwu.edu">gedare@gwu.edu</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Jun 26, 2015 at 9:42 AM, Sebastian Huber<br>
<<a href="javascript:;" onclick="_e(event, 'cvml', 'sebastian.huber@embedded-brains.de')">sebastian.huber@embedded-brains.de</a>> wrote:<br>
> On 26/06/15 15:28, Gedare Bloom wrote:<br>
>><br>
>> Since this thread got migrated to devel a bit prematurely, I'll<br>
>> back-stop some of the details and how I understand the state of this<br>
>> project.<br>
>><br>
>> Saurabh is working toward solving <a href="https://devel.rtems.org/ticket/2124" target="_blank">https://devel.rtems.org/ticket/2124</a><br>
>> (so yes there is a ticket already, and it  should be referenced by<br>
>> patches accordingly). As a first step he has proposed a modified way<br>
>> to step-down inherited priorities when multiple mutexes are acquired<br>
>> simultaneously by one thread and contended by others, i.e. nested<br>
>> mutex access. We wanted assurance the proposal is sound, so we had him<br>
>> implement a model of the current thread synchronization of RTEMS<br>
>> within a Java-based model-checking framework, called Java Path Finder,<br>
>> or JPF. His model shows the existing error with the current<br>
>> STRICT_ORDER option, and then does not show a problem using his<br>
>> proposed method for solving nested mutex acquisition.<br>
>><br>
>> However, validating the proposed method apparently required adding a<br>
>> global lock around the two linked lists that are used in Saurabh's<br>
>> proposed solution. My intuition is that the global lock to protect<br>
>> these lists is not a big problem for uniprocessor, and for SMP we<br>
>> should prefer to find other solutions at any rate. The lists should<br>
>> not be long, and we should be able to find their bounds. One list is<br>
>> bounded by the number of mutexes a thread may hold, and the other by<br>
>> the number of threads that may contend a specific mutex.<br>
><br>
><br>
> Does this new approach address the problem here:<br>
><br>
> <a href="https://git.rtems.org/rtems/tree/testsuites/sptests/spsem03/init.c" target="_blank">https://git.rtems.org/rtems/tree/testsuites/sptests/spsem03/init.c</a><br>
><br>
Perhaps Saurabh can comment and model this problem too, and then we<br>
can see. As I understood the test, a low-priority task holding<br>
semaphore A blocks a mid-priority task holding semaphore B (contending<br>
A), and then a high-priority task blocks on semaphore B, elevating the<br>
priority of mid, but not low => a priority inversion occurs.<br>
<br>
If Saurabh's solution iterates the mutexes held by mid when elevating<br>
its priority, then this inversion also should be fixed.<br>
<br>
Gedare<br>
<br>
><br>
> --<br>
> Sebastian Huber, embedded brains GmbH<br>
><br>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
> Phone   : +49 89 189 47 41-16<br>
> Fax     : +49 89 189 47 41-09<br>
> E-Mail  : <a href="javascript:;" onclick="_e(event, 'cvml', 'sebastian.huber@embedded-brains.de')">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>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'devel@rtems.org')">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
_______________________________________________<br>
devel mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'devel@rtems.org')">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div><br><br>-- <br><div dir="ltr">Thanks,<div><br></div><div>Saurabh Gadia</div></div><br>