Is there a way to give a mutex from a task other than the one that initially took it?
I have a situation where the task that took a mutex may be deleted before the mutex is released. This is due to a timeout recovery mechanism in 3rd party code. As part of the timeout recovery I can check to see if the mutex is held by the recently deleted task, but trying to give that mutex from the timeout recovery task is treated as a bug.
No, you can not give a Mutex from a task that is not the task that took it.
I would say that deleting a task that is currently holding a Mutex is itself a bug.
If a task fails to meet its timing, and the only idea you have is to delete it, then the better response is to just restart the processor, as you have no idea what state you are currently in.
I would also say that in my opinion, deleting another task, except as part of a protocol where the task signals that it is all done and has finished all its cleanup and is just blocking waiting to die, is an error, so unless you know the state of everything the task allocates, you don’t know what you have to do. It is best to let tasks clean up for themselves.
And, if the task isn’t behaving as expected, you have no idea what is actually happening, so recovery is always a guess, so unless you don’t mind not knowing the state you system is in, a clean recovery is normally the best.
Of course, safety critical code needs to be different, but then safety critical code shouldn’t get into that state in the field.
I don’t disagree with any of that. I’ve been thouroughly underwhelmed with the 3rd party code in question, and much of it is a head scratcher. Their own documentation specifies that the driver needs to be reset if certain timeouts occur. For the most part it is self contained and it does reset to a known initial state. The problem is that it makes use of a SPI bus, and that is the mutexed resource it sometimes claims and then fails to release.
well, as the old saying goes… you can’t make buggy code better by adding more bugs. If you have control over the mutex creation code, you can try replacing the mutex with a binary semaphore (which can be signalled externally), but that is more of a crutch than a solution.