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)