Patch for nested mutex project solving priority inversion problem for uniprocessor.

[Sebastian Huber]

On 07/09/15 08:32, Cyrille Artho wrote:
> Hi Sebastian,
> I was not aware that deadlock detection was an objective.

It would be good to first clarify the requirements for a new mutex 
implementation. This is why I created the ticket. It doesn't make sense 
to add something which will be replaced in some months if we add OMIP 
support.

> Cyclic lock usage could be detected but performance would decrease.

I think cyclic lock usage detection will be a simple side-effect of the 
horizontal nesting support. On SMP this is crucial since otherwise we 
may end up in a deadlock at spin lock level and this is bad.

> Furthermore, this would also create possible issues with scheduling
> fairness, so we would have to discuss that first.

What do you mean with scheduling fairness problems?

> Deadlock detection for shared conditionals would be difficult, at
> least in the general case.
>
> On Mon, Sep 7, 2015 at 3:04 PM, Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
>> Hello Saurabh,
>>
>> On 05/09/15 01:52, Saurabh Gadia wrote:
>>> 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:
>>> https://github.com/saurabhgadia4/rtems/tree/nested-mutex
>>
>> 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?)
>>
>> Since all tests pass, test sptests/spsem03 passes, which shows that your
>> implementation doesn't support horizontal nesting.
>>
>> There is no deadlock detection.
>>
>> Please have a look at:
>>
>> https://devel.rtems.org/ticket/2412
>>
>> I think the suggested implementation would even work on SMP systems quite
>> well.
>>
>> --
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> Phone   : +49 89 189 47 41-16
>> Fax     : +49 89 189 47 41-09
>> E-Mail  : sebastian.huber at embedded-brains.de
>> PGP     : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>
>
>

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.