Chapter 3 – Threads & Processes

Introduction
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

1
 3.1 Threads and their Implementation
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
• 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 2
 Class discussion

1. Process scheduling
2. PCBs
3. why context switching

3
 Process 1 Process 2 Process 3

processes each with one thread one process with three threads

4
5
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.

6
 Threads take turns in running
• 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.

7
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

8
In non distributed systems, threads can be used with shared data
instead of processes to avoid context switching overhead inter
process communication (IPC)

9
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
10
• 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
11
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
 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

13
 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
14
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 15
 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

16
 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
17
 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)

18
 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

19
 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 20
Summary of models of code migration

21
Types of Process-to-Resource Bindings
• 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

• 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

• Binding by type (weakest): a process needs a resource of a specific type;

reference to local devices, such as monitors, printer

22
 Resource-to-Machine Bindings
• 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

23
 Assignment Two

1. Homogeneous Ds
2. Heterogeneous Ds

24