Download Threads - Rose

Threads
Processes and Threads

Two characteristics of “processes”
as considered so far:



Unit of resource allocation
Unit of dispatch
Characteristics are separable


Processes (or tasks) are allocated
resources
Threads (or lightweight processes) are
dispatched
What is a thread?


A set of threads have shared access to
the resources of a process (including
memory)
Each thread has its own thread control
block (TCB).



Since each thread has its own TCB, it also has
its own PC, GP registers, and state.
Each thread also has its own kernel stack,
user stack, and space for static variables
A thread is a unit of dispatching within a
process.
Threads in modern operating systems



Single-threading - Only 1 process
(DOS) or 1 thread per process
(flavors of UNIX).
Multi-threading - More than 1
thread in 1 process and many
processes - Solaris, W2K, LINUX.
One process many threads – Java
runtime environment.
Why threads?





Less time to create a thread
Less time to delete a thread
Switching between threads of the same process is
faster
Communication between threads within a single
process is more efficient than communication
between processes
On shared-memory multi-processor systems,
threads can be scheduled on different processors
Thread examples



Web server
Word processor
Others?
4.4 Thread States: Life Cycle of a
Thread
Figure 4.2 Thread life cycle. [Deitel et al]
User level threads and kernel level
threads
User level threads (Many to one
mapping)



Implement thread creation/manipulation using
procedure calls to a user-level library rather than
system calls.
 ULTs can run on any OS, as long as the thread
library is available.
The thread management is done by the application
and the kernel is unaware of threads.
 Allows the user to use scheduling algorithms that
are more appropriate to the application.
Switching between threads is done without invoking
the kernel and the only context that needs to be
saved is the program counter, user registers and
stack pointers. (Threads voluntarily give up the
CPU).
User level threads (Many to one
mapping)


OS is unaware of the threads and
schedules independent of number of
threads per process.
 If the application does require
system calls, then when a thread
gets blocked, process itself gets
blocked.
In a multi-processing environment, the
kernel cannot schedule different threads
of a process on different processors as it
is unaware of the threads.
Kernel-level threads (KLT) (One to one
mapping)

OS is aware of all the threads.






Switch between threads requires a mode switch - still
inexpensive as the context is still small - more expensive
than ULT as mode switch required.
OS schedules the threads and hence if a thread blocks
a process need not block.
Can be efficiently used in a multi-processing
environment.
Less portable as the code has to be re-written to use
the API of the under-lying OS. Use of POSIX threads
reduces this problem.
A lot of overhead on the OS as a process may have
100s of threads and this would result in thousands of
dispatch units for the OS to manage.
Linux supports the one-to-one i.e. KLT model. Efficient
mode (context) switching mechanism is available.
Combined approach (many to many or
m-to-n approach)




Windows XP and old versions of Solaris
A process may have a number of ULTs
and these can be mapped to smaller
number or equal number of KLTs.
By allowing the mapping, we can reduce
the number of threads, the OS sees. The
programmer can select which threads
(blocking threads) are seen by the kernel
separate from the non-blocking.
Creation, synchronization etc. are done at
the application level.
If one were to generalize,

It could be said that

ULTs result in a much faster execution
time than KLTs which are much faster
than processes.