richard_damon wrote on Friday, September 14, 2012:
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?