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