Nested mutexes and priority inheritance (again)

ladislavlaska wrote on Monday, June 12, 2017:


For the last day and a bit, I’ve been debugging a problem with nested mutexes and priority inheritance on FreeRTOS 9.0.0. The flow was as follows (mutexes are FS and SPI, Task3 has priority 3, Task1 has 1):

Task1: Take(FS), Take(SPI);
Task3: Take(SPI) – taken, Task1 inherits priority 3
Task1: Give(SPI) – but xTaskPriorityDisinherit seems to fail, as it also holds the FS mutex
Task1: Take(SPI) … until Give(SPI), Give(FS).
Task3: takes spi and does it’s job.

However, the FS operation is quite long and should have been interrupted by Task3. After I looked at the code I realized, that the priority inheritance algorithm is extremely simplified and doesn’t handle our case, due to multiple mutexes taken at the same time.

This is fine, however, it would be nice if the documentation would alert us to the limitations, as even after knowing what the problem is, I only found out some information in the forums. There seems to be some reference to the docs, but I didn’t find it.

Furthermore, do you have any suggestion on how to solve the problem above? Obviously I need to make sure that the priority gets disinherited, and I probably could write some code myself to do that in the task (as it gives back the mutex, decrease the priority). Other solution is to use mutexes only when the priority inheritance is necessary and binary semaphores everywhere else. However, I’ve got the feeling that both solutions will come and bite me back later.


rtel wrote on Thursday, June 15, 2017:

Sorry for the delay in replying:

You are right that the priority inheritance mechanism is simplified. It was considered the best compromise between code size and functionality. A full priority inheritance mechanism is very complex and involves stacking priorities, two way associations, priority ordered lists of tasks waiting on mutexes, etc. As it is, if a task takes two mutexes, it will not di-inherit any inherited priority until both mutexes have been given back.

I’ve just looked in the book, and you are right, this does need documenting better (at all).

Version 9.0.1, which is currently only available from the SVN repository directly, had some work done on improving prioritiy inheritance, but I can’t recall exactly what (without looking through the check-in comments).

It may be the code can be re-factored to avoid the situation you describe, but that would require a lot more information on your system and some time to determine (which is outside the scope of our support here).

ladislavlaska wrote on Monday, June 19, 2017:


No problem at all, I’m glad you answered!

I looked at the new code, if you meant 2478, which is the only one talking about priority inheritance. Unfortunately, it solves issues when the higher priority task times-out before the task inheriting it’s priority returned the mutex. This doesn’t apply to our case.

However, I have devised another approach to our problem – we will use BinarySemaphore in place of mutex, where the inheritance isn’t necessary. If I read the code correctly, using BinarySemaphore doesn’t increase the task’s uxMutexesHeld, as the sempahore isn’t a mutex (uxQueueType isn’t queueQUEUE_IS_MUTEX). As such, it won’t intefere with the priority inheritance of the few mutexes that actually need this feature. It will however be the same size and have the same semantics.

Does this solution look right? Especially if there are other differences between the BinarySemaphore and Mutex – the documentation doesn’t mention anything and I haven found any other differences in the code.


rtel wrote on Monday, June 19, 2017:

You are correct - the only difference between the binary semaphore and a
mutex is the priority inheritance.