T-Kernel Specification (1.B0.02)

108 CHAPTER 4. T-KERNEL/OS FUNCTIONS
• When a task is no longer locking any mutexes.
When the current priority of a task is changed in connection with a mutex operation, the following
processing is performed. If the task whose priority changed is in a run state, the task precedence is
changed in accord with the new priority. Its precedence among other tasks having the same priority is
implementation-dependent. Likewise, if the task whose priority changed is waiting in a queue of some
kind, its order in that queue is changed based on its new priority. Its order among other tasks having
the same priority is implementation-dependent.
When a task terminates and there are mutexes still locked by that task, all the mutexes are unlocked. The
order in which multiple locked mutexes are unlocked is implementation-dependent. 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.
[Rationale for the Specification]
The precedence of tasks having the same priority as the result of a change in task current priority in a
mutex operation is left as implementation-dependent, for the following reason.
Depending on the application, the mutex function may lead to frequent changes in current priority. It
would not be desirable for this to result in constant task switching, which is what would happen if the
precedence were made the lowest each time among tasks of the same priority. Ideally task precedence
rather than priority should be inherited, but that results in large overhead in implementation. This
aspect of the specification is therefore made an implementation-dependent matter.
Copyright c○ 2002, 2003 by T-Engine Forum
T-Kernel 1.B0.02