Mutex

A mutex is an object for mutual exclusion control among tasks that use shared resources. Priority inheritance mutexes and priority ceiling mutexes are supported as tools for managing the problem of unbounded priority inversion that can occur in mutual exclusion control. Functions are provided for creating and deleting a mutex, locking and unlocking a mutex, and referencing mutex status. A mutex is identified by an ID number called a mutex ID.

A mutex has a status (locked or unlocked) and a queue for tasks waiting to lock the mutex. For each mutex, µT-Kernel keeps track of the tasks locking it; and for each task, it keeps track of the mutexes it has locked. Before a task uses a resource, it locks a mutex corresponding to that resource. If the mutex is already locked by another task, the task waits for the mutex to become unlocked. Tasks in mutex lock waiting state are put in the mutex queue. When a task finishes with a resource, it unlocks the mutex. A mutex with TA_INHERIT (= 0×02) specified as mutex attribute supports priority inheritance protocol, while one with TA_CEILING (= 0×03) specified supports priority ceiling protocol. When a priority ceiling mutex is created, a ceiling priority is assigned to it, indicating the base priority of the task having the highest base priority among the tasks able to lock that mutex. If a task having a higher base priority than the ceiling priority of the mutex tries to lock it, error code E_ILUSE is returned. If tk_chg_pri is issued in an attempt to set the base priority of a task locking a priority ceiling mutex to a value higher than the ceiling priority of that mutex, E_ILUSE is returned by the tk_chg_pri system call.

When these protocols are used, unbounded priority inversion is prevented by changing the current priority of a task in a mutex operation. The current priority of the task should be modified to always match the maximum value of the following priorities:

  • The task base priority.
  • When tasks lock priority inheritance mutexes, the current priority of the task having the highest current priority of the tasks waiting for those mutexes.
  • When tasks lock priority ceiling mutexes, the ceiling priority of the mutex having the highest ceiling priority among those mutexes.

Note that when the current priority of a task waiting for a priority inheritance mutex changes as the result of a base priority change brought about by mutex operation or tk_chg_pri, it may be necessary to change the current priority of the task locking that mutex. This is called dynamic priority inheritance. Further, if this task is waiting for another priority inheritance mutex, dynamic priority inheritance processing may be necessary also for the task locking that mutex.

When the current priority of a task is changed in connection with a mutex operation, the following processing is performed. If a task with modified priority is in executable state, the task precedence shall be changed according to the modified priority. Among tasks which have the same priority as the modified priority, the task precedence shall be changed to the lowest precedence. Even when the task with modified priority is linked to any priority queue, the task priority in the queue shall be changed according to the modified priority. Among tasks which have the same priority as the modified priority, the task priority shall be changed to the lowest priority. If any mutex locked by the task still remains when the task is completed, all those mutexes shall be unlocked. If multiple mutexes are locked, they are unlocked in the reverse order of allocation. See the description of tk_unl_mtx for the specific processing involved.

[Additional Notes]

A TA_TFIFO attribute mutex or TA_TPRI attribute mutex has functionality equivalent to that of a semaphore with a maximum of one resource (binary semaphore). The main differences are that a mutex can be unlocked only by the task that locked it, and a mutex is automatically unlocked when the task locking it terminates.

The term “priority ceiling protocol” is used here in a broad sense. The protocol described here is not the same as the algorithm originally proposed. Strictly speaking, it is what is otherwise referred to as a highest locker protocol or by other names.

When the change in current priority of a task due to a mutex operation results in that task’s order being changed in a priority-based queue, it may be necessary to release the waiting state of other tasks waiting for that task or for that queue.

Comments

Click here to Post a Comment