The
mi_switch
function implements the machine independent prelude to a thread context
switch.
It is called from only a few distinguished places in the kernel
code as a result of the principle of non-preemptable kernel mode execution.
The various major uses of
mi_switch
can be enumerated as follows:
- From within
sleep(9),
tsleep(9)
and
msleep(9)
when the current thread
voluntarily relinquishes the CPU to wait for some resource to become
available.
- After handling a trap
(e.g. a system call, device interrupt)
when the kernel prepares a return to user-mode execution.
This case is
typically handled by machine dependent trap-handling code after detection
of a change in the signal disposition of the current process, or when a
higher priority thread might be available to run.
The latter event is
communicated by the machine independent scheduling routines by calling
the machine defined
need_resched.
- In the signal handling code
(see
issignal(9))
if a signal is delivered that causes a process to stop.
- When a thread dies in
thread_exit(9)
and control of the processor can be passed to the next runnable thread.
- In
thread_suspend_check(9)
where a thread needs to stop execution due to the suspension state of
the process as a whole.
mi_switch
records the amount of time the current thread has been running in the
process structures and checks this value against the CPU time limits
allocated to the process
(see
getrlimit(2)).
Exceeding the soft limit results in a
SIGXCPU
signal to be posted to the process, while exceeding the hard limit will
cause a
SIGKILL.
If the thread is still in the
TDS_RUNNING
state,
mi_switch
will put it back onto the run queue, assuming that
it will want to run again soon.
If it is in one of the other
states and KSE threading is enabled, the associated
KSE
will be made available to any higher priority threads from the same
group, to allow them to be scheduled next.
After these administrative tasks are done,
mi_switch
hands over control to the machine dependent routine
cpu_switch,
which will perform the actual thread context switch.
cpu_switch
first saves the context of the current thread.
Next, it calls
choosethread
to determine which thread to run next.
Finally, it reads in the saved context of the new thread and starts to
execute the new thread.
cpu_throw
is similar to
cpu_switch
except that it does not save the context of the old thread.
This function is useful when the kernel does not have an old thread
context to save, such as when CPUs other than the boot CPU perform their
first task switch, or when the kernel does not care about the state of the
old thread, such as in
thread_exit
when the kernel terminates the current thread and switches into a new
thread.
To protect the
runqueue(9),
all of these functions must be called with the
sched_lock
mutex held.