Communication between RTX tasks--Mutex

void Os_mut_init (
os_id mutex); /* The mutex to initialize */


Initializes a mutex with an internal count of 0, and the mutex type must be os_mut. The mutex must first be initialized with this function before calling the mutex correlation function.


Os_result os_mut_wait (
OS_ID Mutex,/* The mutex to acquire */
U16 timeout); /* Length of time to wait */


return value:
Os_r_ok gets the mutex, locks the mutex back
Os_r_mut task hangs, acquires a mutex before timing out, locks the mutex back
Os_r_tmo waits for a mutex timeout to return.


This function is used to obtain a mutex,
1. If the mutex is not locked (count 0), add the mutex count to 1 and return to OS_R_OK,
2. If the mutex is locked, the task calling the function hangs (in the case of a timeout!=0).
3. When the mutex is obtained before the timeout, the function returns Os_r_mut and returns OS_R_TMO after the timeout.


Mutex uses the priority inheritance mechanism to solve the problem of priority inversion, such as the global variable g is protected by mutex, task a priority is 1, need to access the global variable, so the first possession of the mutex,
When task A also accesses the full local variable, switch to task B with priority 2 running, B also wants to access the global variable G, so call os_mut_wait to get the mutex, but task a now occupies the mutual
And the priority is lower than task B, then os_mut_wait the priority of task A to 2 (priority of task B), let task a run first, task a accesses the full local variable g, call Os_mut_release
When the mutex is released, task a priority is restored to 1.


The parameter mutex type must be Os_mut, timeout is the time-out, system tick, 0 and 0xFFFF are special values:
Timeout=0, getting the mutex will return immediately OS_R_TMO
Timeout=0xffff means infinite wait


Os_result Os_mut_release (
os_id mutex); /* The mutex to release */


return value:
OS_R_OK Mutex Unlocked successfully
Os_r_nok unlock Error: 1. The internal count of the mutex is 0 2. The task calling this function is not the owner of the mutex (such as task a lock mutex, but task B to unlock)


If task a occupies a mutex of M, task A can continue calling os_mut_wait to get the mutex m, then os_mut_wait simply adds 1 to the mutex count and returns.
When calling Os_mut_release to unlock mutexes,


1. If the mutex internal counter is >=1, subtract 1 from the count and return OS_R_OK.
2. Mutex internal count is 0, return Os_r_nok

Communication between RTX tasks--Mutex