0% found this document useful (0 votes)
6 views32 pages

Ch3 Processes

Chapter 3 discusses processes and threads in distributed systems, highlighting the differences between processes and threads, and the benefits of multi-threading. It covers context switching, thread implementation approaches, and the importance of virtualization in cloud computing and code migration. The chapter concludes with various models for code migration and the challenges associated with migrating code in heterogeneous systems.

Uploaded by

asnake ketema
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
6 views32 pages

Ch3 Processes

Chapter 3 discusses processes and threads in distributed systems, highlighting the differences between processes and threads, and the benefits of multi-threading. It covers context switching, thread implementation approaches, and the importance of virtualization in cloud computing and code migration. The chapter concludes with various models for code migration and the challenges associated with migrating code in heterogeneous systems.

Uploaded by

asnake ketema
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 32

CHAPTER 3: Processes

Course Code: CoSc 4038


Distributed
Introduction Systems

 Process is a program in execution


 Process ≠ program
 The program is only part of a process;
 One program can be several processes
 Components of a process
 The program code, also called text section
 Current activity including: program counter, processor registers
 Stack:- containing temporary data
 Function parameters, return addresses, local variables
 Data section : containing global variables
 Heap :- a memory that is dynamically allocated during run time
2
Distributed
Thread Systems
 Thread is a basic unit of CPU utilization;
 Belongs to a process
 Is a flow of control within a process
 consists of a program counter (PC), a register set, and a stack
 A process can have a single or multiple thread

3
Distributed
Context Switching Systems

 A technique used for pausing what the system is doing and taking on
another “possibly” urgent job.
 During a context switch, a system shall:
1. Save the context of the current job so that it can resume back from where it has left
off
2. Load the context of the new job

 Note:- Context switching is an overhead

4
Distributed
Benefits of multi-threading Systems

 Avoid needless blocking


 Blocking system calls does not stop the process (just switch to another thread)
 Exploit parallelism
 It is possible to exploit parallelism on multi-processor computers
 Avoid process switching
 Structure large applications not as collection of process, but through multiple threads.
 Thread switching is easy as it can be done entirely in user-space

 Avoid Inter-Process Communication(IPC) among single-threaded processes


 Most of IPC mechanisms requires kernel’s intervention
 That in turn results in user to kernel mode switching => Expensive
 However, threads can use shared data for communication as all share same address space.
6
Distributed
Observations Systems

 Threads share the same address space.


 Thread context switching can be done entirely independent of the
operating system.
 Process switching is generally more expensive
 Because it involves the OS in the loop, i.e., trapping to the kernel.
 Creating and destroying threads is much cheaper than doing so
for processes. Because:
 Threads can be created and destroyed independent of the OS
 Creating thread consumes less resources than process
7
Distributed
Thread Implementation Systems

 Threads are generally provided in the form of a thread package.


 Thread package contains:
 Operations to create and destroy threads.
 Operation to schedule threads
 Operations on synchronization variables (mutexes and conditional variables).

 Three approaches to thread package implementation:


 User-Level Solution
 Kernel-Level Solution
 Lightweight Process (LWP) Solution
8
Distributed
User level solution Systems

 All operations can be completely handled within a single process.


 All services provided by the kernel are done on behalf of the process in
which a thread resides.
 Pros:
 Cheap to create and destroy threads.
 Fast thread context switching.
 Cons:
 If the kernel decides to block a thread, then entire process will be blocked.
 Threads are used when there are lots of external events: (threads block on a
per-event basis ) if the kernel can’t distinguish threads, how can it support signaling
events to them?

9
Distributed
Kernel-level solution Systems

 The whole idea is to have the kernel contain the implementation


of a thread package.
 All operations return as system calls -> results in user-space to
kernel-space context switch (Expensive)
 Pros:
 Operations that block a thread are no longer a problem:
 the kernel schedules another available thread within the same p
rocess.
 External events are simple: the kernel (which catches all events)
schedules the thread associated with the event.

10
Distributed
Cont… Systems

 Cons:
 Expensive:
 Every thread operation (creation, deletion, synchronization, etc.) will have to be carried
out by the kernel.
 Thread context switching may become as expensive as process context switching.
 Another Solution:
 Mixing user-level and kernel-level threads into a single concept.
 Light-weight process
 The performance gain is compromised by its complexity
 This concept has been virtually abandoned – it’s just either user-level or kernel-level threads.

11
Distributed
Threads in Distributed Systems Systems

 Threads allow blocking calls without blocking the entire process


 This makes them interesting to be used by both clients and servers in
distributed system
 Multi-threaded client use threads to realize distribution transparency
 Example: web browsers use threads to hide communication/network/
latency
 Different parts that make up a page are fetched by different threads
 Start displaying data while it is still coming in
 Displays text till images and videos arrived

12
Distributed
Cont… Systems

 Multiple request-response calls to other machines (Remote


Procedure Call)
 A client does several calls at the same time, each one by a
different thread.
 It then waits until all results have been returned.
 Note: if calls are to different servers, we may have a linear
speed-up.

13
Distributed
Multi-threaded servers Systems

 Uses of multithreading at the server side in distributed system includes:


 Improving performance
 Starting a thread to handle an incoming request is much cheaper than starting a
process.
 Exploits parallelism to attain high performance.
 Single-threaded server can’t take advantage of multiprocessor.
 Hides network latency.
 Other work can be done while a request is coming in.
 Better structure
14
 Multithreaded programs tend to be easier to understand due to simplified flow of control.
Distributed
Multithreaded Servers Systems

 A popular multithreaded server organization is dispa


tcher/worker model.
 Dispatcher thread reads incoming requests.
 Worker thread is selected by the server to process a request.

Figure. A multithreaded
server organized in a
15 dispatcher/worker model.
Distributed
Virtualization Systems

 Virtualization refers to the act of creating a virtual (rather than actual ) version of
something,
 Such as computer hardware platforms, storage devices, and computer network resources.
 It is a logical separation of the request for some service from the physical resources
that actually provide that service
 Why virtualization?
 Portability
 Liberates applications, system services, and even the OS that supports them from being tied
to a specific piece of hardware

 Hardware changes faster than software


 It allows to focus on logical operating environments rather than physical ones „
16
Distributed
Cont… Systems

 The core idea: provide logical access to physical resources!


 Some forms of Virtualization
 1. Application virtualization
 Byte code, Common Intermediate Language (CIL)
 2. Desktop virtualization
 thinclient
 3. Network virtualization
 virtual private networks
 4. Server or machine virtualization (!)
 VirtualPc, VMWare, Virtualbox

17
Distributed
The Role of Virtualization in DS Systems

Figure (a) General organization between a program (b) General organization of virtualizing system A on top
, interface, and system. of system B.

18
Distributed
Architectures of Virtual Machines Systems

 Computer systems often offer four types of interfaces


 An interface between the hardware and software consisting of machine instructions
 (General Instructions) that can be invoked by any program.

 An interface between the hardware and software, consisting of machine instructions


 (Privileged Instruction) that can be invoked only by privileged programs, such as an operating system
.

 An interface consisting of system calls offered by an OS


 An interface consisting of library calls
 known as an application programming interface (API).
 In many cases, the system calls are hidden by an API.

19
Distributed
Logic View of Four Interfaces Systems

 Generally, Virtualization can take place at very different levels, strongly depending on
the interfaces as offered by various systems components

 Figure. Various interfaces offered by computer systems.

20
Distributed
Ways of virtualization Systems
 Often, virtualization can take place in two different ways
 Build runtime system that provides instruction set to be used for executing applications
 Instructions can be interpreted (JVM)
 Instructions can be emulated (Running Windows applications on Unix platforms (Wine)
 The emulator has to mimic the system calls
 Provide a system that is essentially implemented as a layer completely shielding the origin
al hardware
 The layer is called virtual machine monitor (VMM)
 It offers the complete instruction set of that same (or other hardware) as an interface
 Examples: VirtualBox, VMware
21
Distributed
Process VMs versus VM Monitors Systems

 (a). Process VM: A program is compiled to intermediate (portable) code, which is then executed by a runtime s
ystem (Example: Java VM).
 (b) VM Monitor: A separate software layer mimics the instruction set of hardware ) a complete operating syste
m and its applications can be supported (Example: VMware, VirtualBox).

22
Distributed
VMs and cloud computing Systems

 Three types of cloud services


 Infrastructure-as-a-Service covering the basic infrastructure
 Platform-as-a-Service covering system-level services
 Software-as-a-Service containing actual applications
 Virtualization plays a key role in IaaS
 Infrastructure-as-a-Service (IaaS)
 Instead of renting out a physical machine, a cloud provider will rent out a VM (or VM
M) that may possibly be sharing a physical machine with other customers
 Allows for almost complete isolation between customers (although performance isol
ation may not be reached).

23
Distributed
Code Migration Systems

 It is an act of moving a piece of code/process from one machine to another


 Reasons for code migration
 Load balancing
 Improving performance by moving process from heavily-loaded system to l
ightly-loaded system /Load balancing/
 Provide flexibility,
 i.e., clients don’t have to pre-install all software
 Minimizing communication costs
 The communication b/n client and server is only to move the code
 The remaining task can run on the client machine
 Improving scalability
 More users and devices can be added with less performance cost
24
Distributed
Flexibility Systems

 Moving code to a client when needed


 The client first fetches the necessary software, and then invokes the
server.

 Figure The principle of dynamically configuring a client to communicate to a server.

25
Distributed
Code Migration Examples Systems

 Example 1: (Send Client code to Server)


 In a client-Server system, the server holds a huge database.
 If a client needs to perform many database operations, it may be better to
 Ship part of the client application to the server and server sends only the res
ults across the network.

 Example 2: (Send Server code to Client)


 In many interactive DB applications, clients need to fill in forms that are subsequently tra
nslated into a series of DB operation
 The validation of the form can be done at server side, but
 We can move the validation code to the client side:
 To save the computation power of the server
 To reduce Server-Client communication cost
26
Distributed
Cont... Systems

 Example 3:
 System administrator may be forced to shut down a server but does not want to
stop the running processes (e.g. to change a part or even permanent shut down)
 Temporarily freeze an environment, move to another machine and unfreeze
(e.g. for debugging server production issues)

27
Distributed
Approaches to Code Migration Systems

 A process consists of three segments


 Code segment: contains the actual code
 Resource segment: contains references to external resources needed by
the process. E.g., files, printers, devices, other processes
 Execution segment: stores the current execution state of a process, consi
sting of private data, the stack, and the program counter
 Code migration might move either some or all these segments

28
Distributed
Approaches to Code Migration Systems

 Weak mobility
 Move only code segment and some initialization data (and reboot execution):
 The transferred program always start as new. E.g Java Applets
 Strong Mobility:- Migrate all three segments
 Migration: move entire object from one machine to the other
 A process could be stopped, moved to another machine and resumed
execution where it left off.
 Cloning: start a clone, and set it in the same execution state.
 Multiple copies could run in parallel

29
Distributed
Models for Code Migration Systems

 Mobility of code can be


 Receiver-Initiated: Receiver requests code
 Sender-initiated: Sender pushes code

 Figure. Alternatives for code migration.

30
Distributed
Migration and Local Resource Systems

 Problem
 An object uses local resources that may or may not be available at the target
site.
 Resource Types:
 Fixed Resources: bound to a specific machine or environment and can not be
moved (e.g. Local disk drives, communication ports)
 Re-Bind to locally available resources
 Unattached resources: can easily be moved (e.g. Data files)
 Move
 Fastened resources: may be possible but very costly (e.g. local databases or c
omplete web sites)
 Global references
31
Distributed
Migration in Heterogeneous Systems
Systems

 Main problem
 The target machine may not be suitable to execute the migrated code
 The definition of process/thread/processor context is highly dependent on local
hardware, operating system and runtime system
 Only solution - Virtualization
 Make use of an abstract machine that is implemented on different platforms:
 Interpreted languages, effectively having their own VM
 Virtual machine monitors allowing migration of complete OS + apps.
 Takes considerable time
 During migration service will be unavailable
32
End of Chapter-3

33

You might also like