Chapter 3 – Threads & Processes

Introduction: In wide-area distributed systems, is moving processes

between different machines.
Communication takes place between processes a process is a program in
execution.
From OS perspective, management and scheduling of processes is
important.
Other important issues arise in distributed systems Multi threading to
enhance performance by overlapping communication and local processing
How are clients and servers organized and server design issues process or
code migration to achieve scalability and to dynamically configure clients
and servers.
A process is often defined as a program in execution, that is, a program that is
currently being executed on one of the operating system's virtual processors.
12/24/2024 8:26:09 AM 1
 3.1 Threads and their Implementation
• Although processes form a building block in distributed systems, practice indicates
that the granularity of processes as provided by the operating systems on which
distributed systems are built is not sufficient.
• How are processes and threads related?
• Process tables or PCBs are used to keep track of processes, there are
usually many processes executing concurrently.
• Processes should not interfere with each other; sharing resources by
processes is transparent.
• This concurrency transparency has a high price; allocating resources for
a new process and context switching take time.

12/24/2024 8:26:10 AM 2
Cont.
• a thread also executes independently from other threads; but no
need of a high degree of concurrency transparency thereby
resulting in better performance
• What is the difference b/n thread and process?
• threads can be used in both distributed and non distributed systems
• Threads in Non distributed Systems
• a process has an address space (containing program text and data)
and a single thread of control, as well as other resources such as
open files, child processes, accounting information, etc.

12/24/2024 8:26:10 AM 3
 Process 1 Process 2 Process 3

processes each with one thread one process with three threads

12/24/2024 8:26:10 AM 4
each thread has its own program counter, registers, stack, and state; but
all threads of a process share address space, global variables and other
resources such as open files, etc.

12/24/2024 8:26:10 AM 5
 Threads take turns in running
• Like a process, a thread executes its own piece of code,
independently from other threads. However, in contrast to
processes, no attempt is made to achieve a high degree of
concurrency transparency if this would result in performance
degradation.
• Threads allow multiple executions to take place in the same process
environment, called multi threading
• Thread Usage –Why do we need threads?
• e.g., a word processor has different parts for
• interacting with the user
• formatting the page as soon as changes are made
• timed savings (for auto recovery)
• spelling and grammar checking, etc.

12/24/2024 8:26:10 AM 6
1.Simplifying the programming model: since many activities are going
on at once more or less independently
2.They are easier to create and destroy than processes since they do
not have any resources attached to them
3.Performance improves by overlapping activities if there is too much
I/ O; i. e., to avoid blocking when waiting for input or doing
calculations, say in a spreadsheet
• 4. Real parallelism is possible in a multiprocessor system

12/24/2024 8:26:10 AM 7
 In non distributed systems, threads can be used with shared data
instead of processes to avoid context switching overhead
interprocess communication (IPC).

12/24/2024 8:26:10 AM 8
 Thread Implementation
• threads are usually provided in the form of a thread package
• the package contains operations to create and destroy a thread,
operations on synchronization variables such as mutexes and condition
variables
• two approaches of constructing a thread package
a. construct a thread library that is executed entirely in user mode (the
OS is not aware of threads)
• cheap to create and destroy threads; just allocate and free memory
• context switching can be done using few instructions; store and
reload only CPU register values
• disadvantage: invocation of a blocking system call will block the
entire process to which the thread belongs and all other threads in
that process
b. implement them in the OS’s kernel
• let the kernel be aware of threads and schedule them
• expensive for thread operations such as creation and deletion since
each requires a system call
12/24/2024 8:26:10 AM 9
Thread States
• New,
• running,
• waiting
• Blocked
• Timed waiting and
• Termination states

12/24/2024 8:26:10 AM 10
 There are the following two ways to create a thread:
• By Extending Thread Class
• By Implementing Runnable Interface
• Thread Class
• Eg. class Multi extends Thread{
public void run(){
System.out.println("thread is running...");
}
public static void main(String args[]){
Multi t1=new Multi();
t1.start();
} }
12/24/2024 8:26:10 AM 11
class Multi3 implements Runnable{
public void run(){
System.out.println("thread is running...");
}
public static void main(String args[]){
Multi3 m1=new Multi3();
Thread t1 =new Thread(m1); // Using the constructor Thread(Runnabl
e r)
t1.start();
} }

12/24/2024 8:26:10 AM 12
 • solution: use a hybrid form of user-level and kernel-level threads,
called lightweight process (LWP)
• Threads in Distributed Systems
• Multithreaded Clients
• consider a Web browser; fetching different parts of a page can
be implemented as a separate thread, each opening its own
TCP connection to the server
• each can display the results as it gets its part of the page
• parallelism can also be achieved for replicated servers since
each thread request can be forwarded to separate replicas
• Multithreaded Servers
• servers can be constructed in three ways
A. single-threaded process it gets a request, examines it, carries
it out to completion before getting the next request
12/24/2024 8:26:10 AM 13
 b. Threads
• threads are more important for implementing servers
• e.g., a file server
• the dispatcher thread reads incoming requests for a file operation from clients and
passes it to an idle worker thread
C. finite-state machine
• if threads are not available
• it gets a request, examines it, tries to fulfill the request from cache, else
sends a request to the file system

Model Characteristics
Single-threaded process No parallelism, blocking system calls
Threads Parallelism, blocking system calls (thread only)
Finite-state machine Parallelism, non blocking system calls

12/24/2024 8:26:10 AM 14
 3.2 Anatomy of Clients
Two issues: user interfaces and client-side software for
distribution transparency
A. User Interfaces
• to create a convenient environment for the interaction of a
human user and a remote server; e.g. mobile phones with
simple displays and a set of keys
• GUIs are most commonly used
• The X Window System (or simply X) as an example
• it has the X kernel: the part of the OS that controls the
terminal (monitor, keyboard, pointing device like a mouse)
and is hardware dependent

12/24/2024 8:26:10 AM 15
 b. Client-Side Software for Distribution Transparency
• In addition to the user interface, parts of the processing and data level
in a client-server application are executed at the client side

• An example is embedded client software for ATMs, cash registers, etc.

• Moreover, client software can also include components to achieve

distribution transparency

• e.g., replication transparency

• Assume a distributed system with replicated servers; the client proxy

can send requests to each replica

12/24/2024 8:26:10 AM 16
 3.3 Servers and Design Issues
3.3.1 General Design Issues
a. How to organize servers?
Iterative server
• the server itself handles the request and returns the result
Concurrent server
• it passes a request to a separate process or thread and waits for
the next incoming request; e.g., a multithreaded server;
b. Where do clients contact a server?
• using endpoints or ports at the machine where the server is
running where each server listens to a specific endpoint
• how do clients know the endpoint of a service?
• globally assign endpoints for well-known services; e.g. FTP is on
TCP port 21, HTTP is on TCP port 80
12/24/2024 8:26:10 AM 17
 3.4 Code Migration
• so far, communication was concerned on passing data
• we may pass programs, even while running and in
heterogeneous systems
• code migration also involves moving data as well: when a
program migrates while running, its status, pending signals, and
other environment variables such as the stack and the program
counter also have to be moved

12/24/2024 8:26:10 AM 18
 Reasons for Migrating Code
• To improve performance; move processes from heavily-loaded
to lightly-loaded machines (load balancing)

• To reduce communication: move a client application that

performs many database operations to a server if the database
resides on the server; then send only results to the client

• To exploit parallelism (for nonparallel programs): e.g., copies of

a mobile program (called a mobile agent is called in search
engines) moving from site to site searching the Web
12/24/2024 8:26:10 AM 19
 Models for Code Migration
• Code migration doesn’t only mean moving code; in some cases, it also means moving the
execution status of a program, pending signals, and other parts of the execution
environment

• A process consists of three segments: code segment (set of instructions), resource

segment (references to external resources such as files, printers, ...), and execution
segment (to store the current execution state of a process such as private data, the stack,
the program counter)

• Alternatives for code migration

• weak versus strong mobility
• is it sender-or receiver-initiated
• is it executed at the target process or in a separate process (for weak mobility);
migrate or clone process (for strong mobility)
12/24/2024 8:26:10 AM 20
 Weak Mobility
Transfer only the code segment and may be some initialization data;
in this case a program always starts from its initial stage, e.g. Java
Applets
• execution can be by
• the target process (in its own address space like in Java Applets)
but the target process and local resources must be protected
(security) or
• by a separate process; still local resources must be protected
(security)
• Strong Mobility (or process migration )
• Transfer code and execution segments; helps to migrate a process
in execution; stop execution, move it, and then resume execution
from where it is stopped

12/24/2024 8:26:10 AM 21
 Migration can be
• sender-initiated: the machine where the code resides or is currently running;
e.g., uploading programs to a server; may need authentication or that the
client is a registered one; crawlers(computing a program to make index of
data ) to index Web pages
• receiver-initiated: by the target machine; e.g., Java Applets; easier to
implement

• In a client-server model, receiver-initiated is easier to implement since

security issues are minimized; if clients are allowed to send code (sender-
initiated), the server must know them since they may access resources such
as disk on the server
12/24/2024 8:26:10 AM 22
 Summary of models of code migration

12/24/2024 8:26:10 AM 23
 Types of Process-to-Resource Bindings
• Process migration is the process of transferring a process from one machine to another. The
goal of migration is to move processes from heavily loaded systems to lightly loaded systems to
improve performance and communication. This can be in 3 ways i.e.,:

A. Binding by identifier (the strongest): a resource is referred by its identifier; the process
requires that resource; e.g., a URL to refer to a Web page or an FTP server referred by its
Internet (IP) address

B. Binding by value (weaker): when only the value of a resource is needed; in this case another
resource can provide the same value; e.g., standard libraries of programming languages such as
C or Java which are normally locally available, but their location in the file system may vary
from site to site

C. Binding by type (weakest): a process needs a resource of a specific type; reference to local
devices, such as monitors, printer.
12/24/2024 8:26:10 AM 24
 Resource-to-Machine Bindings
• Resource-to-machine bindings in a distributed system are how resources
relate to the hosting machine. The resource-to-machine binding determines
how a resource reference is changed. There are three types of resource-to-
machine bindings. i.e.

• Unattached Resources: can be easily moved with the migrating program

(such as data files associated with the program)

• Fastened Resources: such as local databases and complete Web sites;

moving or copying may be possible, but very costly

• Fixed Resources: intimately bound to a specific machine or environment

such as local devices and cannot be moved.
12/24/2024 8:26:10 AM 25
 Review Questions
1. The X protocol suffers from scalability problems. How can these problems be tackled?
2. Would it make sense to limit the number of threads in a server process?
3. In the text, we described a multithreaded tile server, showing why it is better than a
single-threaded server and a finite-state machine server. Are there any circumstances in
which a single-threaded server might be better? Give an example.
4. Statically associating only a single thread with a lightweight process is not such a good
idea. Why not?
5. Having only a single lightweight process per process is also not such a good idea. Why
not?
6. Consider a process P that requires access to file F which is locally available on the
machine where P is currently running. When P moves to another machine, it still requires
access to F. If the file-to-

12/24/2024 8:26:09 AM 26
 Thank You!
?

12/24/2024 8:26:10 AM 27