Download Threading

Threading
A thread is a single sequence stream within in a process. Because
threads have some of the properties of processes, they are
sometimes called lightweight processes. In a process, threads
allow multiple executions of streams. In many respect, threads
are popular way to improve application through parallelism. The
CPU switches rapidly back and forth among the threads giving
illusion that the threads are running in parallel. Like a
traditional process i.e., process with one thread, a thread can
be in any of several states (Running, Blocked, Ready or
Terminated).Processes are used to group resources together and
threads are the entities scheduled for execution on the CPU.
Each thread has its own stack. Since thread will generally call
different procedures and thus a different execution history. This
is why thread needs its own stack. An operating system that has
thread facility, the basic unit of CPU utilization is a thread.
A thread has or consists of a program counter (PC), a register
set, and a stack space. Threads are not independent of one other
like processes as a result threads shares with other threads
their code section, data section, OS resources also known as
task, such as open files and signals. Depending on the OS,
threads may have some other private resources too, such as
thread-local storage (effectively, a way of referring to
"variable number X", where each thread has its own private value
of X). The OS will generally attach a bit of "housekeeping"
information to each thread, such as its priority and state
(running, waiting for I/O etc).
Processes Vs Threads
Similarities




Like processes threads share CPU and only one thread active
(running) at a time.
Like processes, threads within a process, threads within a
process execute sequentially.
Like processes, thread can create children.
And like process, if one thread is blocked, another thread
can run.
Differences


Unlike processes, threads are not independent of one
another.
Unlike processes, all threads can access every address in
the task.

Unlike processes, threads are design to assist one other.
Note that processes might or might not assist one another
because processes may originate from different users.
Why Threads?
1. A process with multiple threads makes a great server for
example printer server.
2. Because threads can share common data, they do not need to
use interprocess communication.
3. Because of the very nature, threads can take advantage of
multiprocessors.
Threads are cheap in the sense that
1. They only need a stack and storage for registers therefore,
threads are cheap to create.
2. Threads use very little resources of an operating system in
which they are working. That is, threads do not need new
address space, global data, program code or operating
system resources.
3. Context switching is fast when working with threads. The
reason is that we only have to save and/or restore PC, SP
and registers.
But this cheapness does not come free - the biggest drawback is
that there is no protection between threads.
Advantages of Threads over Multiple Processes

Context
Switching
Threads are very
inexpensive to
create and
destroy, and they
are inexpensive
to represent. For
example, they
require space to
store, the PC,
the SP, and the
general-purpose
registers, but
they do not require space to share memory information,
Information about open files of I/O devices in use, etc.
With so little context, it is much faster to switch between
threads. In other words, it is relatively easier for a
context switch using threads.

Sharing
Treads allow the sharing of a lot resources that
cannot be shared in process, for example, sharing code
section, data section, Operating System resources like open
file etc.
Disadvantages of Threads over Multiprocesses


Blocking
The major disadvantage if that if the kernel
is single threaded, a system call of one thread will block
the whole process and CPU may be idle during the blocking
period.
Security
Since there is, an extensive sharing among
threads there is a potential problem of security. It is
quite possible that one thread over writes the stack of
another thread (or damaged shared data) although it is very
unlikely since threads are meant to cooperate on a single
task.
Single threading (when the OS does not recognize the concept of
thread)
Multithreading (when the OS supports multiple threads of
execution within a single process)
On a single
processor,
multithreadin
g generally
occurs by
time-division
multiplexing
(as in
multitasking)
: the
processor
switches
between
different
threads. This
context switching generally happens frequently enough that the
user perceives the threads or tasks to be running at the same
time. On a multiprocessor or multi-core system, the threads or
tasks will generally run at the same time, with each processor or
core running a particular thread or task. Support for threads in
programming languages varies: a number of languages simply do not
support having more than one execution context inside the same
program executing at the same time. Examples of such languages
include Python, and OCaml, because the parallel support of their
runtime support is limited by the use of a central lock, called
"Global Interpreter Lock" in Python, "master lock" in Ocaml.
Many modern operating systems directly support both time-sliced
and multiprocessor threading with a process scheduler. The
operating system kernel allows programmers to manipulate threads
via the system call interface. Some implementations are called a
kernel thread, whereas a lightweight process (LWP) is a specific
type of kernel thread that shares the same state and information.



MS-DOS: support a single user process and a single thread
UNIX: supports multiple user processes but only supports
one thread per process
Solaris: supports multiple threads
Advantages of Multithreading:




Improve application responsiveness -- Any program in which
many activities are not dependent upon each other can be
redesigned so that each activity is defined as a thread.
For example, the user of a multithreaded GUI does not have
to wait for one activity to complete before starting
another.
Use multiprocessors more efficiently -- Typically,
applications that express concurrency requirements with
threads need not take into account the number of available
processors. The performance of the application improves
transparently with additional processors. Numerical
algorithms and applications with a high degree of
parallelism, such as matrix multiplications, can run much
faster when implemented with threads on a multiprocessor.
Improve program structure -- Many programs are more
efficiently structured as multiple independent or semiindependent units of execution instead of as a single,
monolithic thread. Multithreaded programs can be more
adaptive to variations in user demands than single threaded
programs.
Use fewer system resources -- Programs that use two or more
processes that access common data through shared memory are
applying more than one thread of control. However, each
process has a full address space and operating systems
state. The cost of creating and maintaining this large
amount of state information makes each process much more
expensive than a thread in both time and space. In
addition, the inherent separation between processes can
require a major effort by the programmer to communicate
between the threads in different processes, or to
synchronize their actions.
The thread
scheduler
There are
generally more
threads than
CPUs. Part of a
multithreaded
system is
therefore a
thread scheduler,
responsible for
sharing out the
available CPUs in
some way among
the competing
threads. Note
that in
practically all
modern operating
systems, the thread scheduler is part of the OS itself. So the OS
actually "sees" our different threads and is responsible for the
task of switching between them2. The rationale for handling
threading "natively" in the OS is that the OS is likely to have
the information to make threading efficient (such as knowing
which threads are waiting for I/O and for how long), whereas a
software library may not have this information available. In the
rest of our discussion, we'll generally assume this native
threads model.
Operating systems schedule threads in one of two ways. Preemptive
multithreading is generally considered the superior approach, as
it allows the operating system to determine when a context switch
should occur. Cooperative multithreading, on the other hand,
relies on the threads themselves to relinquish control once they
are at a stopping point. This can create problems if a thread is
waiting for a resource to become available. The disadvantage to
preemptive multithreading is that the system may make a context
switch at an inappropriate time, causing priority inversion or
other negative effects which may be avoided by cooperative
multithreading.
Traditional mainstream computing hardware did not have much
support for multithreading as switching between threads was
generally already quicker than full process context switches.
Processors in embedded systems, which have higher requirements
for real-time behaviors, might support multithreading by
decreasing the thread switch time, perhaps by allocating a
dedicated register file for each thread instead of
saving/restoring a common register file. In the late 1990s, the
idea of executing instructions from multiple threads
simultaneously has become known as simultaneous multithreading.
This feature was introduced in Intel's Pentium 4 processor, with
the name hyper threading
Thread Levels
There are two broad categories of thread implementation:


User-Level Threads -- Thread Libraries.
Kernel-level Threads -- System Calls.
There are merits to both, in fact some OSs allow access to both
levels (e.g. Solaris).
User-Level Threads (ULT)
In this level, the kernel is not aware of the existence of
threads -- All thread management is done by the application by
using a thread library. Thread switching does not require kernel
mode privileges (no mode switch) and scheduling is application
specific
Kernel activity for ULTs:



The kernel is not aware of thread activity but it is still
managing process activity
When a thread makes a system call, the whole process will
be blocked but for the thread library that thread is still
in the running state
So thread states are independent of process states
Advantages and inconveniences of ULT
Advantages:



Thread switching does not involve the kernel -- no mode
switching
Scheduling can be application specific -- choose the best
algorithm.
ULTs can run on any OS -- Only needs a thread library
Disadvantages:


Most system calls are blocking and the kernel blocks
processes -- So all threads within the process will be
blocked
The kernel can only assign processes to processors -- Two
threads within the same process cannot run simultaneously
on two processors
Kernel-Level Threads (KLT)
In this level, All thread management is done by kernel No thread
library but an API (system calls) to the kernel thread facility
exists. The kernel maintains context information for the process
and the threads, switching between threads requires the kernel
Scheduling is performed on a thread basis.
Advantages and inconveniences of KLT
Advantages


the kernel can simultaneously schedule many threads of the
same process on many processors blocking is done on a
thread level
kernel routines can be multithreaded
Disadvantages:

Thread switching within the same process involves the
kernel, e.g. if we have 2 mode switches per thread switch
this results in a significant slow down.
Combined ULT/KLT Approaches
Idea is to
combine the
best of both
approaches
Solaris is an
example of an
OS that
combines both
ULT and KLT






Thread
creation
done in
the user
space
Bulk of
scheduling and synchronization of threads done in
space
The programmer may adjust the number of KLTs
Process includes the user's address space, stack,
process control block
User-level threads (threads library) invisible to
are the interface for application parallelism
Kernel threads the unit that can be dispatched on
processor
the user
and
the OS
a

Lightweight processes (LWP) each LWP supports one or more
ULTs and maps to exactly one KLT
Processes, kernel threads, user threads, and fibers
A process is the "heaviest" unit of kernel scheduling. Processes
own resources allocated by the operating system. Resources
include memory, file handles, sockets, device handles, and
windows. Processes do not share address spaces or file resources
except through explicit methods such as inheriting file handles
or shared memory segments, or mapping the same file in a shared
way. Processes are typically preemptively multitasked.
A kernel thread is the "lightest" unit of kernel scheduling. At
least one kernel thread exists within each process. If multiple
kernel threads can exist within a process, then they share the
same memory and file resources. Kernel threads are preemptively
multitasked if the operating system's process scheduler is
preemptive. Kernel threads do not own resources except for a
stack, a copy of the registers including the program counter, and
thread-local storage (if any).
Threads are sometimes implemented in userspace libraries, thus
called user threads. The kernel is not aware of them; they are
managed and scheduled in userspace. Some implementations base
their user threads on top of several kernel threads to benefit
from multi-processor machines (N: M model). In this article the
term "thread" (without kernel or user qualifier) defaults to
referring to kernel threads. User threads as implemented by
virtual machines are also called green threads.
Fibers are an even lighter unit of scheduling which are
cooperatively scheduled: a running fiber must explicitly "yield"
to allow another fiber to run, which makes their implementation
much easier than kernel or user threads. A fiber can be scheduled
to run in any thread in the same process. This permits
applications to gain performance improvements by managing
scheduling themselves, instead of relying on the kernel scheduler
(which may not be tuned for the application). Parallel
programming environments such as OpenMP typically implement their
tasks through fibers.
Application that Benefits from Threads
In general, any program that has to do more than one task at a
time could benefit from multitasking. For example, a program that
reads input, process it, and outputs could have three threads,
one for each task.
Example: A file server on a LAN
A proxy server satisfying the requests for a number of computers
on a LAN would be benefited by a multi-threaded process.



It needs to handle several file requests over a short
period
Hence more efficient to create (and destroy) a single
thread for each request
Multiple threads can possibly be executing simultaneously
on different processors
Example 2: Matrix Multiplication
Matrix Multiplication essentially involves taking the rows of one
matrix and multiplying and adding corresponding columns in a
second matrix i.e.:
Application that cannot Benefit from Threads
Any sequential process that cannot be divided into parallel task
will not benefit from thread, as they would block until the
previous one completes. For example, a program that displays the
time of the day would not benefit from multiple threads.