rtel wrote on Tuesday, November 24, 2015:
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.