Thread (computing): Difference between revisions

Content deleted Content added
unnecessary to call out source in body #article-section-source-editor
Tags: Mobile edit Mobile app edit iOS app edit
m overlinking #article-section-source-editor
Tags: Mobile edit Mobile app edit iOS app edit
Line 34:
===User threads===
{{anchor|user thread}}
Threads are sometimes implemented in [[User space|userspace]] libraries, thus called ''user threads''. The kernel is unaware of them, so they are managed and scheduled in [[User space|userspace]]. Some implementations base their user threads on top of several kernel threads, to benefit from [[Multiprocessing|multi-processor]] machines ([[#Threading models|M:N model]]). User threads as implemented by [[virtual machine]]s are also called [[green threads]].
 
As user thread implementations are typically entirely in [[userspace]], context switching between user threads within the same process is extremely efficient because it does not require any interaction with the kernel at all: a context switch can be performed by locally saving the CPU registers used by the currently executing user thread or fiber and then loading the registers required by the user thread or fiber to be executed. Since scheduling occurs in userspace, the scheduling policy can be more easily tailored to the requirements of the program's workload.
 
However, the use of blocking system calls in user threads (as opposed to kernel threads) can be problematic. If a user thread or a fiber performs a system call that blocks, the other user threads and fibers in the process are unable to run until the system call returns. A typical example of this problem is when performing I/O: most programs are written to perform I/O synchronously. When an I/O operation is initiated, a system call is made, and does not return until the I/O operation has been completed. In the intervening period, the entire process is "blocked" by the kernel and cannot run, which starves other user threads and fibers in the same process from executing.