Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

kernel_thread_w_arg(9r) [osf1 man page]

kernel_thread_w_arg(9r) 												   kernel_thread_w_arg(9r)

NAME
kernel_thread_w_arg - General: Starts a kernel thread with a calling argument passed in SYNOPSIS
thread_t kernel_thread_w_arg( task_t task, void (*start) (void), void* argument ); ARGUMENTS
Specifies a pointer to a task structure. This pointer identifies the task in which the kernel_thread_w_arg routine starts the newly cre- ated kernel thread. Specifies a pointer to a routine that is the entry point for the newly created kernel thread. Specifies the argument that kernel_thread_w_arg passes to the entry point specified in start. DESCRIPTION
The kernel_thread_w_arg routine creates and starts a kernel thread in the specified task at the specified entry point with a specified argument. The kernel_thread_w_arg routine passes the specified argument to the newly created kernel thread. The kernel_thread_w_arg rou- tine creates and starts a kernel thread with timeshare scheduling. A kernel thread created with timeshare scheduling means that its prior- ity degrades if it consumes an inordinate amount of CPU resources. A kernel module should call kernel_thread_w_arg only for long-running tasks. A kernel module should always attach a kernel thread to the ``first task.'' NOTES
This routine is actually a convenience wrapper for the thread_create routine (which creates the kernel thread) and the thread_start routine (which starts the newly created kernel thread). The kernel_thread_w_arg routine behaves identically to kernel_isrthread except that with kernel_thread_w_arg you can pass an argument to the entry point for the newly created kernel thread. RETURN VALUES
Upon successful completion, kernel_thread_w_arg returns a pointer to the thread structure associated with the kernel thread started at the specified entry point. Kernel modules can use this pointer as a handle to a specific kernel thread in calls to other kernel threads-related routines. SEE ALSO
Routines: kernel_isrthread(9r), thread_create(9r), thread_start(9r) Data Structures: task(9s), thread(9s) kernel_thread_w_arg(9r)

Check Out this Related Man Page

MI_SWITCH(9)						   BSD 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: 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) BSD
November 24, 1996 BSD
Man Page