Provided by: freebsd-manpages_12.2-1_all bug

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:

             1.   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.

             2.   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().

             3.   In  the  signal handling code (see issignal(9)) if a signal is delivered that causes a process
                  to stop.

             4.   When a thread dies in thread_exit(9) and control of the processor can be passed  to  the  next
                  runnable thread.

             5.   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)

Debian                                          November 24, 1996                                   MI_SWITCH(9)