Editing Thread (computing) (section)

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

A common solution to this problem (used, in particular, by many green threads implementations) is providing an I/O API that implements an interface that blocks the calling thread, rather than the entire process, by using non-blocking I/O internally, and scheduling another user thread or fiber while the I/O operation is in progress. Similar solutions can be provided for other blocking system calls. Alternatively, the program can be written to avoid the use of synchronous I/O or other blocking system calls (in particular, using non-blocking I/O, including lambda continuations and/or async/[[await]] primitives<ref>{{Cite AV media |first=Sergey |last=Ignatchenko |title=Eight Ways to Handle Non-blocking Returns in Message-passing Programs: from C++98 via C++11 to C++20 |url=https://www.youtube.com/watch?v=6lXUrvlMXNU |url-status=bot: unknown |archive-url=https://web.archive.org/web/20201125224240/https://www.youtube.com/watch?v=6lXUrvlMXNU&gl=US&hl=en |archive-date=2020-11-25 |publisher=CPPCON |access-date=2020-11-24 }}</ref>).