Chapter 3 - Processes

1
 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
 multithreading to enhance performance
 how are clients and servers organized
 process or code migration to achieve scalability and to
dynamically configure clients and servers

2
 3.1 Threads and their Implementation
 threads can be used in both distributed and nondistributed
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.
Process 1 Process 2 Process 3

three processes each with one thread one process with three threads 3
 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.

4
 Threads take turns in running
 Threads allow multiple executions to take place in the same process
environment, called multithreading
 Thread Usage – Why do we need threads?
 e.g., a word-processor has different parts; 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.
1. Simplifying the programming model: since many activities are going on at
once
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

5
 having finer granularity in terms of multiple threads per process
rather than processes provides better performance and makes it
easier to build distributed applications
 in non-distributed systems, threads can be used with shared data
instead of processes to avoid context switching overhead in inter-
process communication (IPC)

context switching as the result of IPC

6
 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
 disadv: 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
7
 solution: use a hybrid form of user-level and kernel-level threads, called
lightweight process (LWP)
 a LWP runs in the context of a single (heavy-weight) process, and there
can be several LWPs per process
 the system also offers a user-level thread package for some operations
such as creating and destroying threads, for thread synchronization
(mutexes and condition variables)
 the thread package can be shared by multiple LWPs

combining kernel-level lightweight processes and user-level threads

8
 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/IP
connection to the server or to separate and replicated servers
 each can display the results as it gets its part of the page
 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
 the server is idle while waiting for disk read, i.e., system calls
are blocking

9
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
 the worker thread performs a blocking disk read; in which
case another thread may continue, say the dispatcher or
another worker thread

a multithreaded server organized in a dispatcher/worker model

10
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; but instead of blocking it records the
state of the current request and proceeds to the next request
 Summary

Model Characteristics
Single-threaded process No parallelism, blocking system calls
Parallelism, blocking system calls
Threads
(thread only)
Finite-state machine Parallelism, nonblocking system calls
three ways to construct a server

11
 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)
 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
 contains all terminal-specific device drivers through the
library called xlib

12
the basic organization of the X Window System

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 and a client side software can
transparently collect all responses and passes a single return value
to the client application

14
 transparent replication of a server using a client-side solution

 access transparency and failure transparency can also be

achieved using client-side software

15
 3.3 Servers and design issues
3.3.1 General Design Issues
 How to organize servers?
 Where do clients contact a server?
 Whether and how a server can be interrupted
 Whether or not the server is stateless

a. Wow 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; or by forking a new process as is done in Unix

16
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
 for services that do not require preassigned endpoints, it can
be dynamically assigned by the local OS
 IANA (Internet Assigned Numbers Authority) Ranges
 IANA divided the port numbers into three ranges

 Well-known ports: assigned and controlled by IANA

(Internet Assigned Numbers Authority)services, e.g.,
DNS uses port 53
17
 Registered ports: are not assigned and controlled by IANA; can
only be registered with IANA to prevent duplication e.g., MySQL
uses port 3306
 Dynamic ports or ephemeral ports : neither controlled nor
registered by IANA
 how can the client know this endpoint? two approaches
i. have a daemon running and listening to a well-known endpoint; it
keeps track of all endpoints of services on the collocated server
 the client will first contact the daemon which provides it with
the endpoint, and then the client contacts the specific server

18
 Client-to-server binding using a daemon

ii. use a superserver (as in UNIX) that listens to all endpoints and then forks a
process to take care of the request; this is instead of having a lot of servers
running simultaneously and most of them idle

Client-to-Server binding using a superserver

19
c. Whether and how a server can be interrupted
 for instance, a user may want to interrupt a file transfer, may be it was the
wrong file
 let the client exit the client application; this will break the connection to the
server; the server will tear down the connection assuming that the client
had crashed
or
 let the client send out-of-bound data, data to be processed by the server
before any other data from the client; the server may listen on a separate
control endpoint; or send it on the same connection as urgent data as is in
TCP
d. Whether or not the server is stateless
 a stateless server does not keep information on the state of its clients; for
instance a Web server
 soft state: a server promises to maintain state for a limited time; e.g., to
keep a client informed about updates; after the time expires, the client has
to poll

20
  a statefull server maintains information about its clients; for
instance a file server that allows a client to keep a local copy
of a file and can make update operations

3.3.2 Server Clusters

 a server cluster is a collection of machines connected through a
network (normally a LAN with high bandwidth and low latency)
where each machine runs one or more servers
 it is logically organized into three tiers

21
the general organization of a three-tiered server cluster

22
 Distributed Servers
 the problem with a server cluster is when the logical switch (single access
point) fails making the cluster unavailable
 hence, several access points can be provided where the addresses are publicly
available leading to a distributed server e.g., the DNS can return several
addresses for the same host name

23
Thank
You!!!!!!!

24