CS-6206: Introduction to Operating System and Its Application

1
Threads

Module 4: THREADS

Course Learning Outcomes:

1. To introduce the notion of a thread—a fundamental unit of CPU
utilization that forms the basis of multithreaded computer systems
2. To discuss the APIs for the Pthreads, Windows, and Java thread libraries
3. To explore several strategies that provide implicit threading
4. To examine issues related to multithreaded programming
5. To cover operating system support for threads in Windows and Linux

Threads Overview

Despite of the fact that a thread must execute in process, the process and its
associated threads are different concept. Processes are used to group resources together and
threads are the entities scheduled for execution on the CPU. 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). 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.
Benefits
• Responsiveness – may allow continued execution if part of process is blocked,
especially important for user interfaces
• Resource Sharing – threads share resources of process, easier than shared
memory or message passing
• Economy – cheaper than process creation, thread switching lower overhead than
context switching
• Scalability – process can take advantage of multiprocessor architectures

Module 3: Process Management

Single-Threaded and Multi-Threaded Process
Multiprogramming or concurrency is the concept of having multiple executing entities (e.g.,
processes) to effectively utilize system resources. For example, if a system has multiple processes, then the
CPU can switch to another process when one process makes a blocking system call. Multiprogramming is
also essential to effectively utilize multiple computing cores that are common in modern systems.
An application (say, a web server or a file server) that wishes to achieve efficiency via
multiprogramming can fork multiple processes and distribute its work amongst them. However, having a
lot of processes is not efficient because every process consumes memory, and sharing information across
processes is not easy. Threads are a type of light-weight processes that are widely used in such situations.
Every process has a single thread (of execution) by default, but can create several new threads once
it starts. Threads of a process share memory corresponding to the code and data in the memory image of
the process, which makes it easy to share information between them. This is also the reason why creating
threads consumes fewer resources than creating processes. Note that threads can optionally have some
thread-specific data in the memory image. However, threads must have separate user-level stacks, because
they may be executing on different parts of the code.
Because threads can be executing on different parts of the process code, each thread may have
different execution state such as the program counter and CPU register values. Because each thread
represents a separate unit of execution, and one thread of a process can execute while the other blocks.
Therefore, threads save their contexts separately in the PCB (or in separate data structures called TCBs or
thread control blocks, that are linked from the PCB).
POSIX provides an API for creating and managing threads. Linux implements these POSIX threads
or pthreads. When a process creates a thread using pthread create, it provides a pointer to a function that
the thread must run. A thread completes execution when the function exits. The parent process can choose
to wait for all threads it created to complete (this is called a join operation), or it can detach the threads
and not wait for their completion.
Sharing data across threads is easy, as they share all data in the program. However, race conditions
can occur when two threads concurrently update a shared variable. So care must be taken in designing
multi-threaded applications. When updating shared data structures, threads must either access mutually
exclusive portions of the data, or must lock and coordinate when accessing the same data.

Figure 4.1 Single-Threaded and Multi-Threaded Process

 CS-6206: Introduction to Operating System and Its Application
3
Threads

User Threads and Kernel Threads

Most real-life applications are multi-threaded. Some applications spawn a fixed
number of threads, and distribute the work of the application amongst them. For example, a
web server can have a fixed number of “worker” threads. When a request arrives from a
client, a free thread picks up the request and serves it. Having multiple threads also means
that one thread can block while serving a request, without impacting the server’s ability to
serve another request.
So far, our discussions of threads have referred to the threads that an application
program creates. These are called user threads. Do these user threads always map to
separate units of execution at the kernel? That is, are all the threads in an application
scheduled as independent entities by the CPU scheduler? The answer is dependent on the
architecture of the particular OS. The separate threads of execution that the kernel deals with
(e.g., for the purpose of scheduling) are called kernel threads. In some operating systems
(e.g., Linux), there is a oneto-one mapping between user threads and kernel threads. That is,
when an application program creates a thread using the pthreads library, Linux creates a
new kernel object corresponding to the thread. (In fact, Linux creates processes and threads
much the same way, with the only difference being the amount of information that is cloned
during fork.) Thus, there is a one-tone mapping between the POSIX threads created by an
application programs and kernel threads managed by Linux. (Note that Linux also has some
kernel threads that do not correspond to any user threads, but whose sole purpose is to carry
out kernel tasks.)

Multi-Threading Model
Many-To-One Model
Many-to-one model maps many user level threads to one Kernel-level thread. Thread
management is done in user space by the thread library. When thread makes a blocking system call,
the entire process will be blocked. Only one thread can access the Kernel at a time, so multiple
threads are unable to run in parallel on multiprocessors.
If the user-level thread libraries are implemented in the operating system in such a way that
the system does not support them, then the Kernel threads use the many-to-one relationship
modes.

Figure 4.2 Many-To-One Model

Module 3: Process Management

One to One Model
There is one-to-one relationship of user-level thread to the kernel-level thread. This model
provides more concurrency than the many-to-one model. It also allows another thread to run when
a thread makes a blocking system call. It supports multiple threads to execute in parallel on
microprocessors.
Disadvantage of this model is that creating user thread requires the corresponding Kernel
thread. OS/2, windows NT and windows 2000 use one to one relationship model.

Figure 4.3 One-To-One Model

Many-To-Many Model
The many-to-many model multiplexes any number of user threads onto an equal or smaller
number of kernel threads.
The following diagram shows the many-to-many threading model where 6 user level threads
are multiplexing with 6 kernel level threads. In this model, developers can create as many user
threads as necessary and the corresponding Kernel threads can run in parallel on a multiprocessor
machine. This model provides the best accuracy on concurrency and when a thread performs a
blocking system call, the kernel can schedule another thread for execution.

Figure 4.4 Many-To-Many Model

Two-Level Model
The two-level model (known commonly as the many-to-many model) is a strict many-to-
many model with the ability to specifically request a one-to-one binding for individual threads. This
model is probably the best of the choices. Several operating systems now use this model (Digital
UNIX, Solaris, IRIX, HP-UX, AIX). The JVMs on these OSs have the option of using any combination of
bound and unbound threads.
The choice of the threading model is an implementation-level decision for writers of the JVM.
Java itself has no concept of LWPs or threading models. This is a very reasonable choice by the Java
designers; Java programs shouldn't be looking at this kind of low-level detail. Unfortunately, it
brings in a very significant area of possible platform behavior difference.
 CS-6206: Introduction to Operating System and Its Application
5
Threads

Figure 4.5 Two-Level Model

Thread Libraries
A thread library provides the programmer an API for creating and managing threads. There are two
primary ways of implementing a thread library. The first approach is to provide a library entirely in user
space with no kernel support. All code and data structures for the library exist in user space. This means
that invoking a function in the library results in a local function call in user space and not a system call.
The second approach is to implement a kernel-level library supported directly by the operating
system. In this case, code and data structures for the library exist in kernel space. Invoking a function in
the API for the library typically results in a system call to the kernel.
Three main thread libraries are in use today:

1. POSIX Pthreads,
2. Win32, and
3. Java. Pthreads,

The threads extension of the POSIX standard, may be provided as either a user- or kernel-level
library. The Win32 thread library is a kernel-level library available on Windows systems. The Java thread
API allows thread creation and management directly in Java programs. However, because in most
instances the JVM is running on top of a host operating system, the Java thread API is typically
implemented using a thread library available on the host system. This means that on Windows systems,
Java threads are typically implemented using the Win32 API; UNIX and Linux systems often use Pthreads.

Implicit Threading
One way to address the difficulties and better support the design of multithreaded applications is
to transfer the creation and management of threading from application developers to compilers and run-
time libraries. This, termed implicit threading, is a popular trend today.
Implicit threading is mainly the use of libraries or other language support to hide the management
of threads. The most common implicit threading library is OpenMP, in context of C.
OpenMP is a set of compiler directives as well as an API for programs written in C, C++, or FORTRAN
that provides support for parallel programming in shared-memory environments. OpenMP identifies
parallel regions as blocks of code that may run in parallel. Application developers insert compiler directives

Module 3: Process Management

into their code at parallel regions, and these directives instruct the OpenMP run-time library to execute the
region in parallel.
It creates as many threads which are processing cores in the system. Thus, for a dual-core system,
two threads are created, for a quad-core system, four are created; and so forth. Then all the threads
simultaneously execute the parallel region. When each thread exits the parallel region, it is terminated.
OpenMP provides several additional directives for running code regions in parallel, including parallelizing
loops.
In addition to providing directives for parallelization, OpenMP allows developers to choose among
several levels of parallelism. Eg, they can set the number of threads manually. It also allows developers to
identify whether data are shared between threads or are private to a thread. OpenMP is available on several
open-source and commercial compilers for Linux, Windows, and Mac OS X systems.

Thread Pool
Thread pool is a group of pre-instantiated, idle threads which stand ready to be given work. These
are preferred over instantiating new threads for each task when there is a large number of short tasks to
be done rather than a small number of long ones. This prevents having to incur the overhead of creating a
thread a large number of times.

Implementation will vary by environment, but in simplified terms, you need the following:

• A way to create threads and hold them in an idle state. This can be accomplished by having each thread
wait at a barrier until the pool hands it work. (This could be done with mutexes as well.)
• A container to store the created threads, such as a queue or any other structure that has a way to add
a thread to the pool and pull one out.
• A standard interface or abstract class for the threads to use in doing work. This might be an abstract
class called Task with an execute() method that does the work and then returns.
When the thread pool is created, it will either instantiate a certain number of threads to make available or
create new ones as needed depending on the needs of the implementation.

When the pool is handed a Task, it takes a thread from the container (or waits for one to become available
if the container is empty), hands it a Task, and meets the barrier. This causes the idle thread to resume
execution, invoking the execute() method of the Task it was given. Once execution is complete, the thread
hands itself back to the pool to be put into the container for re-use and then meets its barrier, putting itself
to sleep until the cycle repeats.

Multi-Threaded Issues
Multithreaded programs allow the execution of multiple parts of a program at the same time. These parts
are known as threads and are lightweight processes available within the process.
Threads improve the application performance using parallelism. They share information like data segment,
code segment files etc. with their peer threads while they contain their own registers, stack, counter etc.
Some of the issues with multithreaded programs are as follows −
• Increased Complexity − Multithreaded processes are quite complicated. Coding for these can only
be handled by expert programmers.
 CS-6206: Introduction to Operating System and Its Application
7
Threads

• Complications due to Concurrency − It is difficult to handle concurrency in multithreaded

processes. This may lead to complications and future problems.
• Difficult to Identify Errors− Identification and correction of errors is much more difficult in
multithreaded processes as compared to single threaded processes.
• Testing Complications− Testing is a complicated process i multithreaded programs as compared
to single threaded programs. This is because defects can be timing related and not easy to identify.
• Unpredictable results− Multithreaded programs can sometimes lead to unpredictable results as
they are essentially multiple parts of a program that are running at the same time.
• Complications for Porting Existing Code − A lot of testing is required for porting existing code in
multithreading. Static variables need to be removed and any code or function calls that are not
thread safe need to be replaced.

Module 3: Process Management

References and Supplementary Materials
Books and Journals
1. Jang. (2017). Security Strategies in Linux Platforms and Applications
2. William Stallings (2018) Operating Systems: Internals and Design Principles
3. Abraham Silberschatz, Peter B. Galvin, Greg Gagne (2018) Operating System Concepts
4. Shital Vivek Ghate - 2017 Operating System Concepts and Basic Linux Commands
5. K.C. Wang - 2017 Embedded and Real-Time Operating Systems
Online Supplementary Reading Materials
1. Threads; http://www.personal.kent.edu/~rmuhamma/OpSystems/Myos/threads.htm;
2016
Online Instructional Videos
1. Process Management; https://www.youtube.com/watch?v=bS3QuOQgUu8;August 25,
2013