Download Notes by Guydosh on Thread managment

Notes on the Behavior and Management of Threads in a Process
by N. Guydosh
2/27/2002 ==> Updated 2/12/03
The material in Silberschatz’s text on threads (“Applied Operating System Concepts”, 1st ed., chapter
5) may seem confusing when discussing the difference between user threads and kernel threads. In
looking at this distinction, we must distinguish between the location of these threads (user space vs.
kernel space), and the management or control (user managed vs. kernel managed) of these threads.
Stallings book (“Operating Systems”, 4th ed., chapter 4) appears to be more clear in this area. I shall
give an outline here to clarify these concepts.
Silberschatz makes the statement on p. 117 that user threads are supported by a thread library at the
user level. This can indeed be the case. In this case the kernel is oblivious to the existence of user
threads. But in the discussion on kernel threads (implying threads in the kernel?) on pl 118, it is said
that kernel threads are supported directly by the operating system – if these threads are in the kernel,
what else can support them? But what about threads in the user space: they are still there and if they
are also controlled by the kernel they don’t cease being user threads. The only difference is that now
user threads are managed from the kernel rather than from user libraries. Silberschatz’s book on pge
118 does not make this clear. With this being the problem to be clarified, here is an outline based on
Stallings:
Assuming we know what a thread is, let us look at user and kernel threads. Let us use the following
notation:
User Thread – resides in a user process in user space
Kernel Thread – resides in the kernel in kernel space.
User Supported Thread (UST) – a thread supported by the user via the user thread library (see
below). it obviously must be a user thread.
Kernel Supported Thread (KST) – a thread supported by the kernel, it could be either a kernel or
user thread.
This is my own home brewed nomenclature, so when relating it to other references, be careful to
examine the context of these references which will use different nomenclature.
Figure 1
CS350
Spring 03
Thread Management
Page 1
User Supported threads (UST):
In a “pure” UST scheme, all thread management for user threads is done by the application in user
space. The kernel is oblivious to the user threads, all it sees is the user process. This is depicted in
Fig. 1a. All thread support code is in the threads library in user space. The library contains code for
creating and destroying threads, passing messages and data between threads, scheduling thread
execution, and doing any thread context switching overhead. Since the kernel only sees the process
containing these threads, a user thread making a blocking system call (for example I/O) will cause
the kernel to block the entire process and thus all thread activity.
Note that a typical environment having this scheme would be a “non-threaded” (ie., single threaded)
kernel as shown in fig 1a.
Kernel Supported Threads (KST):
In a “pure” KST scheme, all thread management for user threads (and obviously kernel threads ) is
done by the kernel in kernel space. The kernel is now completely in control of the user threads (as
well as kernel threads). This is depicted in fig. 1b. There is no thread support in the application
except for an application-programming interface (API) to the kernel thread management facility. The
kernel thread management facility is implemented as a specific kernel thread for each user thread as
shown in fig. 1b. These special “control” kernel threads associated with user threads perform the same
functions that were done by the thread library in user space for the UST scheme. In this figure the
other kernel threads for doing the various kernel functions are not shown. Now if a user thread
blocks, the kernel will schedule another use thread rather than blocking the entire processes.
The main drawback to this scheme is that the transfer of control from one thread to another within the
same process requites a “mode switch” due moving from user mode to “supervisor” or protect mode in
the kernel, The mode switch has overhead not occurring in the UST scheme.
Note that a typical environment having this scheme would be a multi-threaded kernel as shown in fig
1b.
Combined Approaches:
Some operating systems provide a combined UST/KST scheme (fig. 1c). In this scheme, user thread
creation, most of the scheduling, and thread synchronization are done completely in user space.
Remaining functions are done in kernel space along with the control of all the kernel threads
themselves. As in the UST case, a thread library is used for the thread support provided diretly in user
space. The kernel threads mapped onto the user threads do the remaining support functions in kernel
space. Kernel threads obviously do the OS functions themselves. The key thread support function
done by the kernel threads interfacing the user threads is to allow another user thread to execute
when some other user thread makes a blocking system call, rather than blocking the entire user
process as in the UST case. Multiple user threads from a single application are mapped onto a
smaller or equal number of kernel threads. If there are more user threads than controlling kernel
threads (see fig 1c), then the thread library will multiplex the user threads onto a kernel thread. Thus a
user thread can wait for two reasons: wait to be assigned to a kernel thread, and wait for a blocking
system call to unblock. Solaris threads uses this approach.
CS350
Spring 03
Thread Management
Page 2
Solaris Processes and Threads
Solaris supports four basic concepts:
 Process: The traditional UNIX process
 User Threads: Implemented though threads library residing in the process (user) address
space. User threads are invisible to the operating system.
 Lightweight Processes (LWP): An LPW serves mapping between user threads and kernel
threads. Each LWP supports one or more user threads and maps to exactly one kernel thread.
LWPs are scheduled by the kernel independently, and may execute in parallel in a
multiprocessor environment – a key reason for their existence.
 Kernel Threads: These are the fundamental entities that cab be scheduled and dispatched to
run on one of a number of system processors.
An LWP is visible within the process to an application. It is used only when a user thread needs to
communicate with the kernel, for example a blocking system call. If more than one user thread is
associated with a lesser number of LWPs, then some user threads may have to wait or an LWP to
get freed up before it can make a request to the kernel (for example a blocking I/O call). See
Figure 5.5 in Silberschatz’.
CS350
Spring 03
Thread Management
Page 3