Threads are "light weight processes" (LWPs). The idea is aprocess has five fundamental parts: code ("text"), data (VM),stack, file I/O, and signal tables. "Heavy-weight processes"(HWPs) have a significant amount of overhead when switching: all the tableshave to be flushed from the processor for each task switch. Also, the onlyway to achieve shared information between HWPs is through pipes and "sharedmemory". If a HWP spawns a child HWP using fork(), the only part thatis shared is the text.
Threads reduce overhead by sharing fundamental parts. By sharing theseparts, switching happens much more frequently and efficiently. Also, sharinginformation is not so "difficult" anymore: everything can beshared. There are two types of threads:user-spaceandkernel-space.
User-space avoids the kernel and manages the tables itself. Often thisis called "cooperative multitasking" where the task defines aset of routines that get "switched to" by manipulating the stackpointer. Typically each thread "gives-up" the CPU by callingan explicit switch, sending a signal or doing an operation that involvesthe switcher. Also, a timer signal can force switches. User threads typicallycan switch faster than kernel threads [however, Linux kernel threads' switchingis actually pretty close in performance].
Disadvantages. User-space threads have a problem that a single threadcan monopolize the timeslice thus starving the other threads within thetask. Also, it has no way of taking advantage of SMPs (Symmetric MultiProcessorsystems, e.g. dual-/quad-Pentiums). Lastly, when a thread becomes I/O blocked,all other threads within the task lose the timeslice as well.
Solutions/work arounds. Some user-thread libraries have addressed theseproblems with several work-arounds. First timeslice monopolization canbe controlled with an external monitor that uses its own clock tick. Second,some SMPs can support user-space multithreading by firing up tasks on specifiedCPUs then starting the threads from there [this form of SMP threading seemstenuous, at best]. Third, some libraries solve the I/O blocking problemwith special wrappers over system calls, or the task can be written fornonblocking I/O.
Kernel-space threads often are implemented in the kernel using severaltables (each task gets a table of threads). In this case, the kernel scheduleseach thread within the timeslice of each process. There is a little moreoverhead with mode switching from user->kernel-> user and loadingof larger contexts, but initial performance measures indicate a negligibleincrease in time.
Advantages. Since the clocktick will determine the switching times,a task is less likely to hog the timeslice from the other threads withinthe task. Also I/O blocking is not a problem. Lastly, if properly coded,the process automatically can take advantage of SMPs and will run incrementallyfaster with each added CPU.
Combination
Some implementations support both user- and kernel-space threads. Thisgives the advantages of each to the running task. However, since Linux'skernel-space threads nearly perform as well as user-space, the only advantageof using user-threads would be the cooperative multitasking.
| [Previous Page] | [First Page] | [Dictionary] | [Email Author] | [Next Page] |