Threads in Linux are handled quite differently from most other operating systems due to the open source nature of Linux. Linux is entirely configurable by the user/system administrator, right down to the kernel. Thus, this discussion will first focus on User-level and Kernel-level threads. Also discussed are the general topics regarding whether or not Linux is multithreaded and whether or not Linux programmers consider Linux threads to be better than other operating systems' threads.
Linux was created by Linus Torvalds to be an open-sourcecode version of Unix. Linux is simply, the kernel structure of an operating system, the barebones packaging of what is required. Extra support items most often come in Libraries. Threads are considered to be a part of the kernel but there are various libraries in existance created by other Linux users, due fully to the open-source nature of the product. Since version 1.3.56, Linux has supported kernel-level threading. User-level thread libraries have been around since as early as version 1.0.9.
User-Level Threads
User-level threads avoid the kernel entirely and manages the tables itself. User-level threads employ what is
oftentimes called "cooperative multitasking" where the task defines a set of routines that get "switched to" by manipulating the stack pointer.
The big advantage of user-level threads is they can switch faster than kernel level threads.
One of the main disadvantages is that user-level threads have a problem that a single thread can monopolize the time slice, creating starvation among other threads within the tast. Also, user-level threads have no way of taking advantage of Symmetric MultiProcessor systems like a dual-pentium. Last, when a thread becomes I/O blocked, all other threads within the tast lose the timeslice as well.
Some user-thread libraries have provided solutions to these problems with work-arounds. Timeslice monopolization was addressed by controlling it with an external monitor that uses its own clock tick. I/O blocking can be solved by creating special wrappers over system calls or the task can be written for nonblocking I/O.
Kernel-Level Threads
Kernel-level threads are implemented in the kernel using several tables (each task getting a table of threads). The kernel
schedules each thread within the timeslice of each process. There is more overhead with switching in kernel-level threads but
Linux's kernel-level threads perform nearly as well as user-level.
Linux can operate by using either entirely user-level or entierly kernel-level threads or a combination of both. Advantages for using kernel-level threads is that it's less likely for a thread to monopolize a timeslice. Also, I/O blocking is not a problem. If properly coded, the process can automatically take advantage of SMPs as well and will runn incremently faster with each CPU added.
Is Linux Multithreaded?
The short answer is no. Linux does not support multithreading as these are more likely to crash. Linux prides itself on being
one of the most stable, configurable, and free operating systems on the market (to my knowledge, it's the only stable, configurable, and
free os on the market). With multithreading, there are several objects that are hidden from applications and may be shared inadvertently.
Additionally, there are conflicts between some libraries, which is an inherrent problem with open-source solutions (each coder has a vision
of what is good and that differs from coder to coder). For example, SVGAlib & LinuxThreads both use SIGUSR1 and SIGUSR2, which are application-reserved signals. If an
application were to use these libraries together, the application would, at best, have problems. The more likely result would be that it would
crash. Debugging such conflicts is a nightmare. There is an attempt within the open source community to get the libraries in
sync with each other.
Are Linux Threads better?
This is, simply, a matter of opinion. Many linux die-hards believe that the Linux thread libraries are better than any other implementation
out there while mostly keeping the same API. Then again, these are the same people who believe Bill Gates is the anti-christ, that Windows
has set the industry back ten years rather than moving forward, and that all programs should have configurable kernels.
Their argument rests on the belief that Linux is an inherrently more stable OS than many. Linus Torvalds defined a thread as "a context of execution" which means that only one process/thread table and one scheduler is needed. Obviously, this lends to stability because there is less risk of conflict.
As Linux threads are mainly contained in libraries, I have included a table of Linux Thread Packages on a separate page.
