xTaskPriorityDisinherit fails in configAssert

Hello, We upgraded FreeRTOS from v8.0.1 to v8.2.3 and now for a priority mutex (created using xSemaphoreCreateMutex) it triggers an assert in xTaskPriorityDisinherit function, this configASSERT( pxTCB == pxCurrentTCB ) line 3495 was not present in previous version of FreeRTOS. The way we use this mutex is we call: Thread1 (low priority): xSemaphoreTake(handle, 0) //0 timeout to clear a delayed give from Thread2 -do some processing and set timeout to 600ms xSemaphoreTake(handle, timeout) -continue processing. Thread2 (high priority): -process response xSemaphoreGive(handle). pxTCB is Thread1 and pxCurrentTCB is Thread2. Basically we are trying to use it as an event to continue processing in Thread1 when the mutex was given in Thread2. Any idea what’s wrong with this assert and why was it introduced? Best regards, David.

xTaskPriorityDisinherit fails in configAssert

It was introduced after some optimisation in the code that gives a mutex from an ISR. One of the sub, sub functions called by the disinherit function is not safe to call from an ISR and a task simultaneously, hence the assert was added to allert people to this. In this case though I’m not sure that you need to be using a mutex – can you use a binary semaphore instead? If you are just signalling one task from another you might even be able to use a direct to task notification, which is available in V8.2.3 (http://www.freertos.org/RTOS-task-notifications.html) Regards.

xTaskPriorityDisinherit fails in configAssert

But the assert shouldn’t fail since we are calling from different threads. Maybe that assert should be ISR aware or not called at all? Indeed we could use a different mechanism but this means many changes to a code that was working and I believe we need the priority change of the mutex. Aren’t binary semaphores supposed to be used for ISRs and not mutexes, as I’ve seen in their documentation? Best regards, David.

xTaskPriorityDisinherit fails in configAssert

Apologies – ignore the last post – I was talking about a different assert(), and the reply was not relevant. You are talking about this assert(), right? ~~~~ /* A task can only have an inherited priority if it holds the mutex. If the mutex is held by a task then it cannot be given from an interrupt, and if a mutex is given by the holding task then it must be the running state task. */ configASSERT( pxTCB == pxCurrentTCB ); ~~~~ This is actually another place where some code enhancements were made, in this case allowing a task to hold multiple mutexes, and ensuring it only disinherited a priority when it had given all the mutexes it was holding back (and not when it just gave the first one back). A mutex is intended to be used as a mechanism for mutual exclusion. When used for mutual exclusion a task will take the mutex before it accesses a resource, and then must give the mutex back after it has finished accessing the resource in order to allow other tasks the possibility of accessing the same resource. In this scenario it is always expected that the task giving the mutex back is the task that took the mutex in the first place (something a lot of RTOSes insist on) – and the enhanced implementation assumes this is the case. The priority inheritance mechanism is the only difference between a binary semaphore and a mutex, and the priority inheritance mechanism is only useful when using a mutex to guard access to a shared resource. If you are not using a mutex in that scenario then use a binary semaphore instead – your code should not need to change other than the function used to create the semaphore in the first place. Regards.

xTaskPriorityDisinherit fails in configAssert

Yes, that was the line of code that was triggering the assert. I’ve changed to binary semaphore and seems to be working fine now. Thank you for additional clarification for when to be used binary semaphore versus mutex. Best regards, David.