I have a high priority error recovery taks which needs to clear all the mutexes and semaphores of lower level tasks, so that it can resume in a known state. Is it okay for this higher level task to give a mutex that it didn’t take in the first place so that it will be available in the lower level tasks when they need it to syncronise access to a resource? Thanks.

I don’t know if FreeRTOS will have a problem with this, but from the way you phrase your question, I suspect your program will. Having one task release the mutex that another task has aquired becuase it has detected a “problem” is almost always wrong.  The issue being that the task that had the mutex will still think it has it, and will continue accessing the resource, possible with a contention issue. If it was ok to access without owning the mutex, then the mutex wasn’t needed anyway. The most like result is changing a problem that you know, but might not know the cause of, into a problem that you have no idea what it is and how it might present itself. The options for the high priority error recovery task tends to be things like:
1) Reboot the system so everything come up into a know state, perhaps passing it some information to allow some activity to be resumed with a reduced loss of state to the outside world. 2) reboot a subsystem. This does require careful design that the sub-system reboot can’t contaminate the rest of the enviroment. 3) The error recovery task just sends messages to the various tasks asking them to clear their state and release the resources, and if this doesn’t work in a given time, fall back to one of the above methods. It is of course much better to have designed the task to not be able to “fail” in the first place, so that they naturally recover from the problems that might arise. If they are doing their job right, then generally an error that requires a “recovery task” will have two options based on system reqirements, reboot or halt, as it means you are now in a state that you decided was impossible and thus you can have no confidence in the current state of the machine. The individual task is the one that most knows what is happening, and how to recover. For it to not do that is a spec/design issue, which can not reliably be fixed with a band-aid like releasing mutexes for different tasks then that took them. Semaphores are perhaps a bit different, but still tend not lend themselves to an error recovery task. If being useds a mutex, all of the above tends to apply, but the FreeRTOS software is unlikely to have an issue as semaphores are not naturally limited to the giver being the previous taker.  If the semaphore is for a more traditional producer/consumor interaction, then the error recovery task can of course gve the semaphore, IF it fulfills the contract associated with that semaphore, but the question then comes, why isn’t the normal producer providing the data? 

Thanks for the reply. I do have HALT and REBOOT situations already but this is for a situation that I can potentially recover from if I can reset and restart about 6 tasks. Each one of those tasks is using semaphores and there is a single mutex shared by 2 tasks to synchronise access to a resource. It has to be a mutex and when the recovery task gets started one of those two tasks may or may not have taken the mutex. The tasks are state machines where the transition between states is governed by semaphores and I need to force all the tasks into a known state. The way I’ve done that is in the error recovery task I loop round giving each task all the possible semaphores it needs to progress through the states until it transitions to the recovery state. Once it gets to the recovery state it suspends and the recovery task then resumes all those suspended tasks when it’s finished doing its stuff. It does appear to work as it is…

Semaphores, other than mutex type semaphores, should not be too problematic, but I would be careful about giving a mutex from a task that does not own it.  Mutexes, unlike other semaphores, note the mutex holder in their structures to allow priority inheritance and disinheritance. Regards.