table of contents
| MI_SWITCH(9) | Kernel Developer's Manual | MI_SWITCH(9) | 
NAME¶
mi_switch,
    cpu_switch, cpu_throw
    — switch to another thread context
SYNOPSIS¶
#include
    <sys/param.h>
  
  #include <sys/proc.h>
void
  
  mi_switch(void);
void
  
  cpu_switch(void);
void
  
  cpu_throw(void);
DESCRIPTION¶
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 a function such as cv_wait(9), mtx_lock(9), or tsleep(9) when the current thread voluntarily relinquishes the CPU to wait for some resource or lock 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.
SEE ALSO¶
cv_wait(9), issignal(9), mutex(9), runqueue(9), tsleep(9), wakeup(9)
| November 24, 1996 | Debian |