Question

So if a thread locks a mutex and then starts a hrtimer. In the timer handler callback function, can I unlock that mutex?

I ask this because I have seen in the mutex.h file:
“only the owner can unlock the mutex”
“task may not exit with mutex held”
“mutexes may not be used in hardware or software interrupt contexts such as tasklets and timers”

So is the timer handler executed in the interrupt context? In that context, the mutex can not be unlocked because the owner is unknow? So maybe I should use semaphore?

Thanks,

---

@Andy Ross Hi, thank you for your reply.I can not type too many words in comment. What I am going to do is a little difficult to explain. For example, we have 4 cores on one socket. core 0 wants to increase its frequency. To to this, it first needs to increase the socket voltage(voltage change is socket level) then change the frequency. During the change process(normally changing voltage will take some time),other core may also want to change the socket’s voltage which should not be allowed. So core 0 first locks a mutex, then issue the change of the voltage command,start a timer and immediately return to run other tasks. When the timer expires, it will check whether the voltage change has been finished or not. If so, it will change the frequency of the core and then unlock the mutex to allow other cores to change the socket’s voltage. So the mutex is socket level.
I think maybe I can use a sleep. If other core tries to change the voltage before the voltage change has finished, they will do a nanosleep() for example.

Answer 1

The answer is NO. Timer runs in other thread. Only the same thread can unlock.

For you problem, you should use a state flag/count in and update it with atomic_set and friends. Use that flag to identify the status, don’t hold a mutex that long.

If you need to queue up voltage change request, use a queue. Blocking a process that long is never a wise idea.