Recently I developed a library. And another engineer use the API of this library in ISR. Actually this API is designed for Task and this API will get mutex , do something, then release mutex.
Then we got strange errors and start to debug.
The mutex is from an OS for embedded system. The logic of lock mutex is:
1. get current task
2. if(mutex.lock == 0) {mutex.lock++ and mutex.owner = current_task, then return OK;}
3. if(mutex.owner == current_task) { mutex.lock ++; return OK}
4. Or switch current_task out of CPU.
So If an ISR break a Task and both Task and ISR try to get the same mutex(Task gets it before ISR try to get it), then ISR can get the same mutex and everything works.
My test confirmed this case.
However, if a Task got the mutex, then switch to another Task before release the mutex, and now ISR comes and try to get the mutex. the current task is not the one who hold the mutex, so ISR can't get the mutex. Then go to step 4 and it gets out of control.
My test confirmed this case too.
So when ISR try to share data with Task, mutex is a wrong choice.