Chapter 3-Processes PDF

Chapter 3-Processes Mulugeta A.(PhD) Introduction  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 c...

Chapter 3-Processes Mulugeta A.(PhD) Introduction  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 Thread  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 Basic idea of Thread  We build virtual processors in software, on top of physical processors:  Processor: Provides a set of instructions along with the capability of automatically executing a series of those instructions.  Thread: A minimal software processor in whose context a series of instructions can be executed.  Saving a thread context implies stopping the current execution and saving all the data needed to continue the execution at a later stage.  Process: A software processor in whose context one or more threads may be executed.  Executing a thread, means executing a series of instructions in the context of that thread. 4 Context Switching  A technique used for pausing what the system is doing and taking on another “possibly” urgent job.  Save the context of the current job so that it can resume back from where it has left off  Load the context of the new job  Context switching is an overhead  Processor context: The minimal collection of values stored in the registers of a processor used for the execution of a series of instructions (e.g., stack pointer, addressing registers, program counter).  Allows to handle interrupt and resume back later on  Thread context: The minimal collection of values stored in registers and memory, used for the execution of a series of instructions (i.e., processor context, state).  Process context: The minimal collection of values stored in registers and memory, used for the execution of a thread (i.e., thread context, but now also at least MMU register values). 5 Observations  Threads share the same address space.  Thread context switching can be done entirely independent of the operating system.  Process switching is generally more expensive  As it involves getting the OS in the loop, i.e., trapping to the kernel.  Creating and destroying threads is much cheaper than doing so for processes. 6 Why use threads  Some simple reasons  Avoid needless blocking: a single-threaded process will block when doing I/O; in a multi-threaded process, the operating system can switch the CPU to another thread in that process.  Exploit parallelism: the threads in a multi-threaded process can be scheduled to run in parallel on a multiprocessor or multicore processor.  Avoid process switching: structure large applications not as a collection of processes, but through multiple threads. 7 Thread Implementation  Threads are generally provided in the form of a thread package.  Thread package contains:  Operations to create and destroy 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 User level solution  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.  Because all thread administration is kept in the user’s address space,  The price of creating a thread is primarily determined by the cost for allocating memory to set up a thread stack.  Analogously, destroying a thread mainly involves freeing memory for the stack, which is no longer used.  Both operations are cheap.  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 Kernel-level solution  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 process.  External events are simple: the kernel (which catches all events) schedules the thread associated with the event. 10  Cont…  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 11 Lightweight processes  Basic idea  Introduce a two-level threading approach: lightweight processes that can execute user-level threads. 12 Principle operation  User-level thread does system call => the LWP that is executing that thread, blocks. The thread remains bound to the LWP.  The kernel can schedule another LWP having a runnable thread bound to it. Note: this thread can switch to any other runnable thread currently in user space.  A thread calls a blocking user-level operation => do context switch to a runnable thread, (then bound to the same LWP).  When there are no threads to schedule, an LWP may remain idle, and may even be removed (destroyed) by the kernel.  Note: This concept has been virtually abandoned – it’s just either user-level or kernel-level threads. 13 Threads in Distributed Systems  Threads allow blocking calls with out 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 14 Cont…  Multiple request-response calls to other machines (RPC)  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. 15 Multi-threaded servers  An important use of multithreading in distributed systems is at the server side.  Main issues are:  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  Multithreaded programs tend to be easier to understand due to simplified flow of control. 16 Multithreaded Servers  A popular multithreaded server organization is dispatcher/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 dispatcher/worker model. 17 Virtualization  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. 18 Cont…  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  Thin client  3. Network virtualization  virtual private networks  4. Server or machine virtualization  Virtual Pc, VMWare , Virtualbox 19 The Role of Virtualization in Distributed Systems Figure (a) General organization between a program, interface, and system. (b) General organization of virtualizing system A on top of system B. 20 Architectures of Virtual Machines  Computer systems often offer four types of interfaces, at three different levels: 1. An interface between the hardware and software, referred to as the instruction set architecture (ISA), forming the set of machine instructions. This set is divided into two subsets  Privileged instructions, which are allowed to be executed only by the operating system.  General instructions, which can be executed by any program. 2. An interface consisting of system calls offered by an OS. 3. An interface consisting of library calls  known as an application programming interface (API).  In many cases, the system calls are hidden by an API. 21 Logic View of the Three Interfaces  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. 22 Ways of virtualization  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 original 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 23 Process VMs versus VM Monitors  (a). Process VM: A program is compiled to intermediate (portable) code, which is then executed by a runtime system (Example: Java VM).  (b) VM Monitor: A separate software layer mimics the instruction set of hardware ) a complete operating system and its applications can be supported (Example: VMware, VirtualBox). 24 Application of virtual machines to distributed systems  From the perspective of distributed systems, the most important application of virtualization lies in cloud computing.  cloud providers offer roughly three different types of 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.  Instead of renting out a physical machine, a cloud provider will rent out a VM (or VMM) that may possibly be sharing a physical machine with other customers  Allows for almost complete isolation between customers (although performance isolation may not be reached). 25 Code Migration  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 lightly-loaded system /Load balancing/  Provide flexibility, i.e., clients don’t have to pre-install all software  Minimizing communication costs  Improving scalability 26 Flexibility  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. 27 Code Migration Examples  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 results across the network.  Example 2: (Send Server code to Client)  In many interactive DB applications, clients need to fill in forms that are subsequently translated 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 28 Cont...  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) 29 Approaches to Code Migration  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, consisting of private data, the stack, and the program counter  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 30 Models for Code Migration  Mobility of code can be  Receiver-Initiated: Receiver requests code  Sender-initiated: Sender pushes code  Figure. Alternatives for code migration. 31 Migration and Local Resource  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 complete web sites)  Global references 32 Migration in Heterogeneous 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 33  End of Chapter 3 34