SlideShare a Scribd company logo
1
Chapter 3 - Processes
2
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
3
3.1 Threads and their Implementation
 threads can be used in both distributed and nondistributed
systems
 Threads in Nondistributed 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
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.
5
 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 wordprocessor 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
6
 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 nondistributed systems, threads can be used with shared
data instead of processes to avoid context switching
overhead in interprocess communication (IPC)
context switching as the result of IPC
7
 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
8
combining kernel-level lightweight processes and user-level threads
 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
9
 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
10
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
11
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
three ways to construct a server
Model Characteristics
Single-threaded process No parallelism, blocking system calls
Threads
Parallelism, blocking system calls
(thread only)
Finite-state machine Parallelism, nonblocking system calls
12
 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
3.2 Anatomy of Clients
13
the basic organization of the X Window System
14
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
15
transparent replication of a server using a client-side solution
 access transparency and failure transparency can also be
achieved using client-side software
16
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
3.3 Servers and design issues
17
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
for standard services, e.g., DNS uses port 53
18
 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
19
Client-to-Server binding using a superserver
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 daemon
20
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
21
 a stateful 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
22
the general organization of a three-tiered server cluster
23
 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
24
 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
3.4 Code Migration
25
 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 (a crawler as is called in search
engines) moving from site to site searching the Web
26
the principle of dynamically configuring a client to communicate to a
server; the client first fetches the necessary software, and then
invokes the server
 to have flexibility by dynamically configuring distributed
systems: instead of having a multitiered client-server
application deciding in advance which parts of a program
are to be run where
27
 Models for Code Migration
 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)
 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) or by a separate
process
28
 Strong Mobility
 transfer code and execution segments; helps to migrate a
process in execution
 can also be supported by remote cloning; having an
exact copy of the original process and running on a
different machine; executed in parallel to the original
process; UNIX does this by forking a child process
 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
 receiver-initiated: by the target machine; e.g., Java
Applets; easier to implement
29
 Summary of models of code migration
alternatives for code migration
30
 Migration and Local Resources
 how to migrate the resource segment
 not always possible to move a resource; e.g., a reference to
TCP port held by a process to communicate with other
processes
 Types of Process-to-Resource Bindings
 Binding by identifier (the strongest): a resource is referred
by its identifier; 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,
printers, ...
31
 in migrating code, the above bindings cannot change, but the
references to resources can
 how can a reference be changed? depends whether the
resource can be moved along with the code, i.e., resource-to-
machine binding
 Types of 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
we have nine combinations to consider
32
actions to be taken with respect to the references to local
resources when migrating code to another machine
Unattached Fastened Fixed
By identifier
By value
By type
MV (or GR)
CP (or MV, GR)
RB (or GR, CP)
GR (or MV)
GR (or CP)
RB (or GR, CP)
GR
GR
RB (or GR)
Resource-to machine binding
Process-to-
resource binding
 GR: Establish a global system wide reference
 MV: Move the resource
 CP: Copy the value of the resource
 RB: Rebind process to a locally available resource
33
 Migration in Heterogeneous Systems
 distributed systems are constructed on a heterogeneous
collection of platforms, each with its own OS and machine
architecture
 heterogeneity problems are similar to those of portability
 easier in some languages
 for scripting languages the source code is interpreted
 for Java an intermediary code is generated by the
compiler for a virtual machine
 in weak mobility
 since there is no runtime information, compile the source
code for each potential platform
 in strong mobility
 difficult to transfer the execution segment since there
may be platform-dependent information such as register
values; Read the book about possible solutions

More Related Content

What's hot

Distributed Systems
Distributed SystemsDistributed Systems
Distributed Systems
Medicaps University
 
Limitations of memory system performance
Limitations of memory system performanceLimitations of memory system performance
Limitations of memory system performance
Syed Zaid Irshad
 
CS9222 ADVANCED OPERATING SYSTEMS
CS9222 ADVANCED OPERATING SYSTEMSCS9222 ADVANCED OPERATING SYSTEMS
CS9222 ADVANCED OPERATING SYSTEMS
Kathirvel Ayyaswamy
 
Design Goals of Distributed System
Design Goals of Distributed SystemDesign Goals of Distributed System
Design Goals of Distributed System
Ashish KC
 
Communication in Distributed Systems
Communication in Distributed SystemsCommunication in Distributed Systems
Communication in Distributed Systems
Dilum Bandara
 
1. Overview of Distributed Systems
1. Overview of Distributed Systems1. Overview of Distributed Systems
1. Overview of Distributed Systems
Daminda Herath
 
HIGH SPEED NETWORKS
HIGH SPEED NETWORKSHIGH SPEED NETWORKS
HIGH SPEED NETWORKS
Kathirvel Ayyaswamy
 
RPC communication,thread and processes
RPC communication,thread and processesRPC communication,thread and processes
RPC communication,thread and processes
shraddha mane
 
Middleware and Middleware in distributed application
Middleware and Middleware in distributed applicationMiddleware and Middleware in distributed application
Middleware and Middleware in distributed application
Rishikese MR
 
Chapter One.ppt
Chapter One.pptChapter One.ppt
Chapter One.ppt
abdigeremew
 
Atm
AtmAtm
2.communcation in distributed system
2.communcation in distributed system2.communcation in distributed system
2.communcation in distributed system
Gd Goenka University
 
Quality of service
Quality of serviceQuality of service
Quality of service
Ismail Mukiibi
 
Distributed system Tanenbaum chapter 1,2,3,4 notes
Distributed system Tanenbaum chapter 1,2,3,4 notes Distributed system Tanenbaum chapter 1,2,3,4 notes
Distributed system Tanenbaum chapter 1,2,3,4 notes
SAhammedShakil
 
Introduction to distributed file systems
Introduction to distributed file systemsIntroduction to distributed file systems
Introduction to distributed file systems
Viet-Trung TRAN
 
Key Challenges In CLOUD COMPUTING
Key Challenges In CLOUD COMPUTINGKey Challenges In CLOUD COMPUTING
Key Challenges In CLOUD COMPUTING
Atul Chounde
 
Distributed Systems Naming
Distributed Systems NamingDistributed Systems Naming
Distributed Systems Naming
Ahmed Magdy Ezzeldin, MSc.
 
Synch
SynchSynch
3a data link layer
3a data link layer 3a data link layer
3a data link layer
kavish dani
 
Chapter 11
Chapter 11Chapter 11
Chapter 11
AbDul ThaYyal
 

What's hot (20)

Distributed Systems
Distributed SystemsDistributed Systems
Distributed Systems
 
Limitations of memory system performance
Limitations of memory system performanceLimitations of memory system performance
Limitations of memory system performance
 
CS9222 ADVANCED OPERATING SYSTEMS
CS9222 ADVANCED OPERATING SYSTEMSCS9222 ADVANCED OPERATING SYSTEMS
CS9222 ADVANCED OPERATING SYSTEMS
 
Design Goals of Distributed System
Design Goals of Distributed SystemDesign Goals of Distributed System
Design Goals of Distributed System
 
Communication in Distributed Systems
Communication in Distributed SystemsCommunication in Distributed Systems
Communication in Distributed Systems
 
1. Overview of Distributed Systems
1. Overview of Distributed Systems1. Overview of Distributed Systems
1. Overview of Distributed Systems
 
HIGH SPEED NETWORKS
HIGH SPEED NETWORKSHIGH SPEED NETWORKS
HIGH SPEED NETWORKS
 
RPC communication,thread and processes
RPC communication,thread and processesRPC communication,thread and processes
RPC communication,thread and processes
 
Middleware and Middleware in distributed application
Middleware and Middleware in distributed applicationMiddleware and Middleware in distributed application
Middleware and Middleware in distributed application
 
Chapter One.ppt
Chapter One.pptChapter One.ppt
Chapter One.ppt
 
Atm
AtmAtm
Atm
 
2.communcation in distributed system
2.communcation in distributed system2.communcation in distributed system
2.communcation in distributed system
 
Quality of service
Quality of serviceQuality of service
Quality of service
 
Distributed system Tanenbaum chapter 1,2,3,4 notes
Distributed system Tanenbaum chapter 1,2,3,4 notes Distributed system Tanenbaum chapter 1,2,3,4 notes
Distributed system Tanenbaum chapter 1,2,3,4 notes
 
Introduction to distributed file systems
Introduction to distributed file systemsIntroduction to distributed file systems
Introduction to distributed file systems
 
Key Challenges In CLOUD COMPUTING
Key Challenges In CLOUD COMPUTINGKey Challenges In CLOUD COMPUTING
Key Challenges In CLOUD COMPUTING
 
Distributed Systems Naming
Distributed Systems NamingDistributed Systems Naming
Distributed Systems Naming
 
Synch
SynchSynch
Synch
 
3a data link layer
3a data link layer 3a data link layer
3a data link layer
 
Chapter 11
Chapter 11Chapter 11
Chapter 11
 

Similar to Chapter 3-Processes2.pptx

distributed-systemsfghjjjijoijioj-chap3.pptx
distributed-systemsfghjjjijoijioj-chap3.pptxdistributed-systemsfghjjjijoijioj-chap3.pptx
distributed-systemsfghjjjijoijioj-chap3.pptx
lencho3d
 
DS-Chapter DDEFR2-Communication_105220.ppt
DS-Chapter DDEFR2-Communication_105220.pptDS-Chapter DDEFR2-Communication_105220.ppt
DS-Chapter DDEFR2-Communication_105220.ppt
menoralemu03
 
Lec+3-Introduction-to-Distributed-Systems.pdf
Lec+3-Introduction-to-Distributed-Systems.pdfLec+3-Introduction-to-Distributed-Systems.pdf
Lec+3-Introduction-to-Distributed-Systems.pdf
samaghorab
 
Internet
InternetInternet
Internet
Jack Nicole
 
Chapter 2B-Communication.ppt
Chapter 2B-Communication.pptChapter 2B-Communication.ppt
Chapter 2B-Communication.ppt
sirajmohammed35
 
Task communication
Task communicationTask communication
Task communication
1jayanti
 
Database System Architectures
Database System ArchitecturesDatabase System Architectures
Database System Architectures
Information Technology
 
Chapter 3-Process in distributed system.ppt
Chapter 3-Process in distributed system.pptChapter 3-Process in distributed system.ppt
Chapter 3-Process in distributed system.ppt
AschalewAyele2
 
Chapter 4 communication2
Chapter 4 communication2Chapter 4 communication2
Chapter 4 communication2
DBU
 
Client Server Model and Distributed Computing
Client Server Model and Distributed ComputingClient Server Model and Distributed Computing
Client Server Model and Distributed Computing
Abhishek Jaisingh
 
Linux Inter Process Communication
Linux Inter Process CommunicationLinux Inter Process Communication
Linux Inter Process Communication
Abhishek Sagar
 
Network Testing ques
Network Testing quesNetwork Testing ques
Network Testing ques
Pragya Rastogi
 
Introduction to the client server computing By Attaullah Hazrat
Introduction to the client server computing By Attaullah HazratIntroduction to the client server computing By Attaullah Hazrat
Introduction to the client server computing By Attaullah Hazrat
Attaullah Hazrat
 
Clientserver
ClientserverClientserver
Clientserver
Madhumithah Ilango
 
Application server
Application serverApplication server
Application server
nava rathna
 
characteristicsofdistributedsystem-121004123308-phpapp02.ppt
characteristicsofdistributedsystem-121004123308-phpapp02.pptcharacteristicsofdistributedsystem-121004123308-phpapp02.ppt
characteristicsofdistributedsystem-121004123308-phpapp02.ppt
RamkumardevendiranDe
 
Lecture5 architecture styles.pdf
Lecture5 architecture styles.pdfLecture5 architecture styles.pdf
Lecture5 architecture styles.pdf
ssuser9d62d6
 
Internetworking
InternetworkingInternetworking
Internetworking
Raghu nath
 
CHP-4.pptx
CHP-4.pptxCHP-4.pptx
CHP-4.pptx
FamiDan
 
Week10 transport
Week10 transportWeek10 transport
Week10 transport
kapilpahwabnb
 

Similar to Chapter 3-Processes2.pptx (20)

distributed-systemsfghjjjijoijioj-chap3.pptx
distributed-systemsfghjjjijoijioj-chap3.pptxdistributed-systemsfghjjjijoijioj-chap3.pptx
distributed-systemsfghjjjijoijioj-chap3.pptx
 
DS-Chapter DDEFR2-Communication_105220.ppt
DS-Chapter DDEFR2-Communication_105220.pptDS-Chapter DDEFR2-Communication_105220.ppt
DS-Chapter DDEFR2-Communication_105220.ppt
 
Lec+3-Introduction-to-Distributed-Systems.pdf
Lec+3-Introduction-to-Distributed-Systems.pdfLec+3-Introduction-to-Distributed-Systems.pdf
Lec+3-Introduction-to-Distributed-Systems.pdf
 
Internet
InternetInternet
Internet
 
Chapter 2B-Communication.ppt
Chapter 2B-Communication.pptChapter 2B-Communication.ppt
Chapter 2B-Communication.ppt
 
Task communication
Task communicationTask communication
Task communication
 
Database System Architectures
Database System ArchitecturesDatabase System Architectures
Database System Architectures
 
Chapter 3-Process in distributed system.ppt
Chapter 3-Process in distributed system.pptChapter 3-Process in distributed system.ppt
Chapter 3-Process in distributed system.ppt
 
Chapter 4 communication2
Chapter 4 communication2Chapter 4 communication2
Chapter 4 communication2
 
Client Server Model and Distributed Computing
Client Server Model and Distributed ComputingClient Server Model and Distributed Computing
Client Server Model and Distributed Computing
 
Linux Inter Process Communication
Linux Inter Process CommunicationLinux Inter Process Communication
Linux Inter Process Communication
 
Network Testing ques
Network Testing quesNetwork Testing ques
Network Testing ques
 
Introduction to the client server computing By Attaullah Hazrat
Introduction to the client server computing By Attaullah HazratIntroduction to the client server computing By Attaullah Hazrat
Introduction to the client server computing By Attaullah Hazrat
 
Clientserver
ClientserverClientserver
Clientserver
 
Application server
Application serverApplication server
Application server
 
characteristicsofdistributedsystem-121004123308-phpapp02.ppt
characteristicsofdistributedsystem-121004123308-phpapp02.pptcharacteristicsofdistributedsystem-121004123308-phpapp02.ppt
characteristicsofdistributedsystem-121004123308-phpapp02.ppt
 
Lecture5 architecture styles.pdf
Lecture5 architecture styles.pdfLecture5 architecture styles.pdf
Lecture5 architecture styles.pdf
 
Internetworking
InternetworkingInternetworking
Internetworking
 
CHP-4.pptx
CHP-4.pptxCHP-4.pptx
CHP-4.pptx
 
Week10 transport
Week10 transportWeek10 transport
Week10 transport
 

More from MeymunaMohammed1

Chapter 6-Synchronozation2.ppt
Chapter 6-Synchronozation2.pptChapter 6-Synchronozation2.ppt
Chapter 6-Synchronozation2.ppt
MeymunaMohammed1
 
Distributed system.pptx
Distributed system.pptxDistributed system.pptx
Distributed system.pptx
MeymunaMohammed1
 
ANS_Ch_05_Handouts.pdf
ANS_Ch_05_Handouts.pdfANS_Ch_05_Handouts.pdf
ANS_Ch_05_Handouts.pdf
MeymunaMohammed1
 
Seminar Course instruction .ppt
Seminar Course instruction .pptSeminar Course instruction .ppt
Seminar Course instruction .ppt
MeymunaMohammed1
 
M.Sc Mobile computing.pptx
M.Sc Mobile computing.pptxM.Sc Mobile computing.pptx
M.Sc Mobile computing.pptx
MeymunaMohammed1
 
Cloud_Ch_01_Handouts(1).pdf
Cloud_Ch_01_Handouts(1).pdfCloud_Ch_01_Handouts(1).pdf
Cloud_Ch_01_Handouts(1).pdf
MeymunaMohammed1
 
ANS_Ch_06_Handouts.pdf
ANS_Ch_06_Handouts.pdfANS_Ch_06_Handouts.pdf
ANS_Ch_06_Handouts.pdf
MeymunaMohammed1
 
ANS_Ch_05_Handouts.pdf
ANS_Ch_05_Handouts.pdfANS_Ch_05_Handouts.pdf
ANS_Ch_05_Handouts.pdf
MeymunaMohammed1
 
ANS_Ch_04_Handouts.pdf
ANS_Ch_04_Handouts.pdfANS_Ch_04_Handouts.pdf
ANS_Ch_04_Handouts.pdf
MeymunaMohammed1
 
Chapter 2-Architectures23.ppt
Chapter 2-Architectures23.pptChapter 2-Architectures23.ppt
Chapter 2-Architectures23.ppt
MeymunaMohammed1
 
Chapter 2-Architectures2.ppt
Chapter 2-Architectures2.pptChapter 2-Architectures2.ppt
Chapter 2-Architectures2.ppt
MeymunaMohammed1
 

More from MeymunaMohammed1 (11)

Chapter 6-Synchronozation2.ppt
Chapter 6-Synchronozation2.pptChapter 6-Synchronozation2.ppt
Chapter 6-Synchronozation2.ppt
 
Distributed system.pptx
Distributed system.pptxDistributed system.pptx
Distributed system.pptx
 
ANS_Ch_05_Handouts.pdf
ANS_Ch_05_Handouts.pdfANS_Ch_05_Handouts.pdf
ANS_Ch_05_Handouts.pdf
 
Seminar Course instruction .ppt
Seminar Course instruction .pptSeminar Course instruction .ppt
Seminar Course instruction .ppt
 
M.Sc Mobile computing.pptx
M.Sc Mobile computing.pptxM.Sc Mobile computing.pptx
M.Sc Mobile computing.pptx
 
Cloud_Ch_01_Handouts(1).pdf
Cloud_Ch_01_Handouts(1).pdfCloud_Ch_01_Handouts(1).pdf
Cloud_Ch_01_Handouts(1).pdf
 
ANS_Ch_06_Handouts.pdf
ANS_Ch_06_Handouts.pdfANS_Ch_06_Handouts.pdf
ANS_Ch_06_Handouts.pdf
 
ANS_Ch_05_Handouts.pdf
ANS_Ch_05_Handouts.pdfANS_Ch_05_Handouts.pdf
ANS_Ch_05_Handouts.pdf
 
ANS_Ch_04_Handouts.pdf
ANS_Ch_04_Handouts.pdfANS_Ch_04_Handouts.pdf
ANS_Ch_04_Handouts.pdf
 
Chapter 2-Architectures23.ppt
Chapter 2-Architectures23.pptChapter 2-Architectures23.ppt
Chapter 2-Architectures23.ppt
 
Chapter 2-Architectures2.ppt
Chapter 2-Architectures2.pptChapter 2-Architectures2.ppt
Chapter 2-Architectures2.ppt
 

Recently uploaded

Programming Foundation Models with DSPy - Meetup Slides
Programming Foundation Models with DSPy - Meetup SlidesProgramming Foundation Models with DSPy - Meetup Slides
Programming Foundation Models with DSPy - Meetup Slides
Zilliz
 
Salesforce Integration for Bonterra Impact Management (fka Social Solutions A...
Salesforce Integration for Bonterra Impact Management (fka Social Solutions A...Salesforce Integration for Bonterra Impact Management (fka Social Solutions A...
Salesforce Integration for Bonterra Impact Management (fka Social Solutions A...
Jeffrey Haguewood
 
Letter and Document Automation for Bonterra Impact Management (fka Social Sol...
Letter and Document Automation for Bonterra Impact Management (fka Social Sol...Letter and Document Automation for Bonterra Impact Management (fka Social Sol...
Letter and Document Automation for Bonterra Impact Management (fka Social Sol...
Jeffrey Haguewood
 
Taking AI to the Next Level in Manufacturing.pdf
Taking AI to the Next Level in Manufacturing.pdfTaking AI to the Next Level in Manufacturing.pdf
Taking AI to the Next Level in Manufacturing.pdf
ssuserfac0301
 
Operating System Used by Users in day-to-day life.pptx
Operating System Used by Users in day-to-day life.pptxOperating System Used by Users in day-to-day life.pptx
Operating System Used by Users in day-to-day life.pptx
Pravash Chandra Das
 
Nordic Marketo Engage User Group_June 13_ 2024.pptx
Nordic Marketo Engage User Group_June 13_ 2024.pptxNordic Marketo Engage User Group_June 13_ 2024.pptx
Nordic Marketo Engage User Group_June 13_ 2024.pptx
MichaelKnudsen27
 
Best 20 SEO Techniques To Improve Website Visibility In SERP
Best 20 SEO Techniques To Improve Website Visibility In SERPBest 20 SEO Techniques To Improve Website Visibility In SERP
Best 20 SEO Techniques To Improve Website Visibility In SERP
Pixlogix Infotech
 
Trusted Execution Environment for Decentralized Process Mining
Trusted Execution Environment for Decentralized Process MiningTrusted Execution Environment for Decentralized Process Mining
Trusted Execution Environment for Decentralized Process Mining
LucaBarbaro3
 
Columbus Data & Analytics Wednesdays - June 2024
Columbus Data & Analytics Wednesdays - June 2024Columbus Data & Analytics Wednesdays - June 2024
Columbus Data & Analytics Wednesdays - June 2024
Jason Packer
 
Fueling AI with Great Data with Airbyte Webinar
Fueling AI with Great Data with Airbyte WebinarFueling AI with Great Data with Airbyte Webinar
Fueling AI with Great Data with Airbyte Webinar
Zilliz
 
GenAI Pilot Implementation in the organizations
GenAI Pilot Implementation in the organizationsGenAI Pilot Implementation in the organizations
GenAI Pilot Implementation in the organizations
kumardaparthi1024
 
HCL Notes and Domino License Cost Reduction in the World of DLAU
HCL Notes and Domino License Cost Reduction in the World of DLAUHCL Notes and Domino License Cost Reduction in the World of DLAU
HCL Notes and Domino License Cost Reduction in the World of DLAU
panagenda
 
Building Production Ready Search Pipelines with Spark and Milvus
Building Production Ready Search Pipelines with Spark and MilvusBuilding Production Ready Search Pipelines with Spark and Milvus
Building Production Ready Search Pipelines with Spark and Milvus
Zilliz
 
Main news related to the CCS TSI 2023 (2023/1695)
Main news related to the CCS TSI 2023 (2023/1695)Main news related to the CCS TSI 2023 (2023/1695)
Main news related to the CCS TSI 2023 (2023/1695)
Jakub Marek
 
Overcoming the PLG Trap: Lessons from Canva's Head of Sales & Head of EMEA Da...
Overcoming the PLG Trap: Lessons from Canva's Head of Sales & Head of EMEA Da...Overcoming the PLG Trap: Lessons from Canva's Head of Sales & Head of EMEA Da...
Overcoming the PLG Trap: Lessons from Canva's Head of Sales & Head of EMEA Da...
saastr
 
How to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdf
How to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdfHow to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdf
How to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdf
Chart Kalyan
 
Presentation of the OECD Artificial Intelligence Review of Germany
Presentation of the OECD Artificial Intelligence Review of GermanyPresentation of the OECD Artificial Intelligence Review of Germany
Presentation of the OECD Artificial Intelligence Review of Germany
innovationoecd
 
Choosing The Best AWS Service For Your Website + API.pptx
Choosing The Best AWS Service For Your Website + API.pptxChoosing The Best AWS Service For Your Website + API.pptx
Choosing The Best AWS Service For Your Website + API.pptx
Brandon Minnick, MBA
 
Monitoring and Managing Anomaly Detection on OpenShift.pdf
Monitoring and Managing Anomaly Detection on OpenShift.pdfMonitoring and Managing Anomaly Detection on OpenShift.pdf
Monitoring and Managing Anomaly Detection on OpenShift.pdf
Tosin Akinosho
 
Skybuffer AI: Advanced Conversational and Generative AI Solution on SAP Busin...
Skybuffer AI: Advanced Conversational and Generative AI Solution on SAP Busin...Skybuffer AI: Advanced Conversational and Generative AI Solution on SAP Busin...
Skybuffer AI: Advanced Conversational and Generative AI Solution on SAP Busin...
Tatiana Kojar
 

Recently uploaded (20)

Programming Foundation Models with DSPy - Meetup Slides
Programming Foundation Models with DSPy - Meetup SlidesProgramming Foundation Models with DSPy - Meetup Slides
Programming Foundation Models with DSPy - Meetup Slides
 
Salesforce Integration for Bonterra Impact Management (fka Social Solutions A...
Salesforce Integration for Bonterra Impact Management (fka Social Solutions A...Salesforce Integration for Bonterra Impact Management (fka Social Solutions A...
Salesforce Integration for Bonterra Impact Management (fka Social Solutions A...
 
Letter and Document Automation for Bonterra Impact Management (fka Social Sol...
Letter and Document Automation for Bonterra Impact Management (fka Social Sol...Letter and Document Automation for Bonterra Impact Management (fka Social Sol...
Letter and Document Automation for Bonterra Impact Management (fka Social Sol...
 
Taking AI to the Next Level in Manufacturing.pdf
Taking AI to the Next Level in Manufacturing.pdfTaking AI to the Next Level in Manufacturing.pdf
Taking AI to the Next Level in Manufacturing.pdf
 
Operating System Used by Users in day-to-day life.pptx
Operating System Used by Users in day-to-day life.pptxOperating System Used by Users in day-to-day life.pptx
Operating System Used by Users in day-to-day life.pptx
 
Nordic Marketo Engage User Group_June 13_ 2024.pptx
Nordic Marketo Engage User Group_June 13_ 2024.pptxNordic Marketo Engage User Group_June 13_ 2024.pptx
Nordic Marketo Engage User Group_June 13_ 2024.pptx
 
Best 20 SEO Techniques To Improve Website Visibility In SERP
Best 20 SEO Techniques To Improve Website Visibility In SERPBest 20 SEO Techniques To Improve Website Visibility In SERP
Best 20 SEO Techniques To Improve Website Visibility In SERP
 
Trusted Execution Environment for Decentralized Process Mining
Trusted Execution Environment for Decentralized Process MiningTrusted Execution Environment for Decentralized Process Mining
Trusted Execution Environment for Decentralized Process Mining
 
Columbus Data & Analytics Wednesdays - June 2024
Columbus Data & Analytics Wednesdays - June 2024Columbus Data & Analytics Wednesdays - June 2024
Columbus Data & Analytics Wednesdays - June 2024
 
Fueling AI with Great Data with Airbyte Webinar
Fueling AI with Great Data with Airbyte WebinarFueling AI with Great Data with Airbyte Webinar
Fueling AI with Great Data with Airbyte Webinar
 
GenAI Pilot Implementation in the organizations
GenAI Pilot Implementation in the organizationsGenAI Pilot Implementation in the organizations
GenAI Pilot Implementation in the organizations
 
HCL Notes and Domino License Cost Reduction in the World of DLAU
HCL Notes and Domino License Cost Reduction in the World of DLAUHCL Notes and Domino License Cost Reduction in the World of DLAU
HCL Notes and Domino License Cost Reduction in the World of DLAU
 
Building Production Ready Search Pipelines with Spark and Milvus
Building Production Ready Search Pipelines with Spark and MilvusBuilding Production Ready Search Pipelines with Spark and Milvus
Building Production Ready Search Pipelines with Spark and Milvus
 
Main news related to the CCS TSI 2023 (2023/1695)
Main news related to the CCS TSI 2023 (2023/1695)Main news related to the CCS TSI 2023 (2023/1695)
Main news related to the CCS TSI 2023 (2023/1695)
 
Overcoming the PLG Trap: Lessons from Canva's Head of Sales & Head of EMEA Da...
Overcoming the PLG Trap: Lessons from Canva's Head of Sales & Head of EMEA Da...Overcoming the PLG Trap: Lessons from Canva's Head of Sales & Head of EMEA Da...
Overcoming the PLG Trap: Lessons from Canva's Head of Sales & Head of EMEA Da...
 
How to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdf
How to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdfHow to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdf
How to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdf
 
Presentation of the OECD Artificial Intelligence Review of Germany
Presentation of the OECD Artificial Intelligence Review of GermanyPresentation of the OECD Artificial Intelligence Review of Germany
Presentation of the OECD Artificial Intelligence Review of Germany
 
Choosing The Best AWS Service For Your Website + API.pptx
Choosing The Best AWS Service For Your Website + API.pptxChoosing The Best AWS Service For Your Website + API.pptx
Choosing The Best AWS Service For Your Website + API.pptx
 
Monitoring and Managing Anomaly Detection on OpenShift.pdf
Monitoring and Managing Anomaly Detection on OpenShift.pdfMonitoring and Managing Anomaly Detection on OpenShift.pdf
Monitoring and Managing Anomaly Detection on OpenShift.pdf
 
Skybuffer AI: Advanced Conversational and Generative AI Solution on SAP Busin...
Skybuffer AI: Advanced Conversational and Generative AI Solution on SAP Busin...Skybuffer AI: Advanced Conversational and Generative AI Solution on SAP Busin...
Skybuffer AI: Advanced Conversational and Generative AI Solution on SAP Busin...
 

Chapter 3-Processes2.pptx

  • 1. 1 Chapter 3 - Processes
  • 2. 2 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
  • 3. 3 3.1 Threads and their Implementation  threads can be used in both distributed and nondistributed systems  Threads in Nondistributed 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
  • 4. 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.
  • 5. 5  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 wordprocessor 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
  • 6. 6  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 nondistributed systems, threads can be used with shared data instead of processes to avoid context switching overhead in interprocess communication (IPC) context switching as the result of IPC
  • 7. 7  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
  • 8. 8 combining kernel-level lightweight processes and user-level threads  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
  • 9. 9  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
  • 10. 10 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
  • 11. 11 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 three ways to construct a server Model Characteristics Single-threaded process No parallelism, blocking system calls Threads Parallelism, blocking system calls (thread only) Finite-state machine Parallelism, nonblocking system calls
  • 12. 12  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 3.2 Anatomy of Clients
  • 13. 13 the basic organization of the X Window System
  • 14. 14 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
  • 15. 15 transparent replication of a server using a client-side solution  access transparency and failure transparency can also be achieved using client-side software
  • 16. 16 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 3.3 Servers and design issues
  • 17. 17 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 for standard services, e.g., DNS uses port 53
  • 18. 18  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
  • 19. 19 Client-to-Server binding using a superserver 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 daemon
  • 20. 20 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
  • 21. 21  a stateful 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
  • 22. 22 the general organization of a three-tiered server cluster
  • 23. 23  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
  • 24. 24  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 3.4 Code Migration
  • 25. 25  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 (a crawler as is called in search engines) moving from site to site searching the Web
  • 26. 26 the principle of dynamically configuring a client to communicate to a server; the client first fetches the necessary software, and then invokes the server  to have flexibility by dynamically configuring distributed systems: instead of having a multitiered client-server application deciding in advance which parts of a program are to be run where
  • 27. 27  Models for Code Migration  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)  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) or by a separate process
  • 28. 28  Strong Mobility  transfer code and execution segments; helps to migrate a process in execution  can also be supported by remote cloning; having an exact copy of the original process and running on a different machine; executed in parallel to the original process; UNIX does this by forking a child process  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  receiver-initiated: by the target machine; e.g., Java Applets; easier to implement
  • 29. 29  Summary of models of code migration alternatives for code migration
  • 30. 30  Migration and Local Resources  how to migrate the resource segment  not always possible to move a resource; e.g., a reference to TCP port held by a process to communicate with other processes  Types of Process-to-Resource Bindings  Binding by identifier (the strongest): a resource is referred by its identifier; 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, printers, ...
  • 31. 31  in migrating code, the above bindings cannot change, but the references to resources can  how can a reference be changed? depends whether the resource can be moved along with the code, i.e., resource-to- machine binding  Types of 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 we have nine combinations to consider
  • 32. 32 actions to be taken with respect to the references to local resources when migrating code to another machine Unattached Fastened Fixed By identifier By value By type MV (or GR) CP (or MV, GR) RB (or GR, CP) GR (or MV) GR (or CP) RB (or GR, CP) GR GR RB (or GR) Resource-to machine binding Process-to- resource binding  GR: Establish a global system wide reference  MV: Move the resource  CP: Copy the value of the resource  RB: Rebind process to a locally available resource
  • 33. 33  Migration in Heterogeneous Systems  distributed systems are constructed on a heterogeneous collection of platforms, each with its own OS and machine architecture  heterogeneity problems are similar to those of portability  easier in some languages  for scripting languages the source code is interpreted  for Java an intermediary code is generated by the compiler for a virtual machine  in weak mobility  since there is no runtime information, compile the source code for each potential platform  in strong mobility  difficult to transfer the execution segment since there may be platform-dependent information such as register values; Read the book about possible solutions

Editor's Notes

  1. 1