Dr Markus Hagenbuchner CSCI319. Distributed Systems Chapter 3 - Processes

Size: px

Start display at page:

Download "Dr Markus Hagenbuchner CSCI319. Distributed Systems Chapter 3 - Processes"

Jean Fields
5 years ago
Views:

1 Dr Markus Hagenbuchner CSCI319 Distributed Systems Chapter 3 - Processes CSCI319 Chapter 3 Page: 1

2 Processes Lecture notes based on the textbook by Tannenbaum Study objectives: 1. Understand the requirement of client side and server side processes. 2. Explain the differences between threads and processes. 3. Explain the purpose of virtualization. 4. Explain the role and mechanisms of code migration. CSCI319 Chapter 3 Page: 2

3 Process Usage in Nondistributed Systems In general, the various processes running on the same system do not share the address space. Address space separation between processes is enforced by the OS. Therefore, if two processes on the same system need to communicate with each other, then this cannot be done directly. Communication needs to be achieved via the OS. One process can only do one thing at a time. It is very hard to have a process handle more than one task at a time (i.e., dealing with multiple client requests concurrently by a single server side process). CSCI319 Chapter 3 Page: 3

4 Process Usage in Nondistributed Systems Interprocess Communication (IPC) between processes in a nondistributed system results in context switching in the OS: Also, creating multiple processes requires a new (protected) address space, and stack. CSCI319 Chapter 3 Page: 4

5 Thread Implementation Threads are lightwight processes (LWP) which share the address space of the parent process. Threads are available through OS support as kernel-level lightweight processes, and user-level threads. A thread can be seen as an execution pointer, each with its own stack. Therefore, there are several execution pointers when executing code using multiple threads. This often requires synchronization between threads. Thread synchronization is done in user space. The programmer has to take care of this. CSCI319 Chapter 3 Page: 5

6 Example: single thread void foo(int d){ int r; r = * d * d / 4; cout << r; } int main(){ int x; foo(7); cout << done ; return 1; } Execution pointer: points at the segment currently being executed. CSCI319 Chapter 3 Page: 6

7 Example: single thread void foo(int d){ int r; r = * d * d / 4; cout << r; } int main(){ int x; foo(7); cout << done ; return 1; } CSCI319 Chapter 3 Page: 7 of 40

8 Example: single thread void foo(int d){ int r; r = * d * d / 4; cout << r; } int main(){ int x; foo(7); cout << done ; return 1; } CSCI319 Chapter 3 Page: 8 of 40

9 Example: single thread void foo(int d){ int r; r = * d * d / 4; cout << r; } int main(){ int x; foo(7); cout << done ; return 1; } CSCI319 Chapter 3 Page: 9 of 40

10 Example: single thread void foo(int d){ int r; r = * d * d / 4; cout << r; } int main(){ int x; foo(7); cout << done ; return 1; } CSCI319 Chapter 3 Page: 10 of 40

11 Example: single thread void foo(int d){ int r; r = * d * d / 4; cout << r; } int main(){ int x; foo(7); cout << done ; return 1; } CSCI319 Chapter 3 Page: 11 of 40

12 Example: single thread void foo(int d){ int r; r = * d * d / 4; cout << r; } int main(){ int x; foo(7); cout << done ; return 1; } One instruction is executed at a time. CSCI319 Chapter 3 Page: 12 of 40

13 Example 2: Multiple threads void foo(int d){ int r; r = * d * d / 4; cout << r; } int main(){ int x, id; id = pthread_create(foo(7)); cout << done ; return 1; } Note: The syntax of pthread_create has been simplified for illustration purposes. Please refer to the documentation of the pthread_create function for the complete syntax. CSCI319 Chapter 3 Page: 13 of 40

14 Example: multiple thread void foo(int d){ int r; r = * d * d / 4; cout << r; } int main(){ int x, id; id = pthread_create(foo, 7); cout << done ; return 1; } Ask OS to create a new execution pointer. Tell OS where the execution pointer is to start. Note: for sake of simplicity, the syntax is not correct here. CSCI319 Chapter 3 Page: 14 of 40

15 Example: multiple thread void foo(int d){ int r; r = * d * d / 4; cout << r; } int main(){ int x, id; id = pthread_create(foo, 7); cout << done ; return 1; } Two execution pointers work in parallel at their own pace and within the same program. CSCI319 Chapter 3 Page: 15 of 40

16 Example: multiple thread void foo(int d){ int r; r = * d * d / 4; cout << r; } int main(){ int x, id; id = pthread_create(foo, 7); cout << done ; return 1; } Program terminates when the parent thread terminates. Thus, thread synchronization is needed to allow other thread to complete its task as well. CSCI319 Chapter 3 Page: 16 of 40

17 Example: multiple thread void foo(int d){ int r; r = * d * d / 4; cout << r; } int main(){ int x, id; id = pthread_create(foo, 7); cout << done ; pthread_join(id); return 1; } Here, pthread_join forces the parent to wait for the termination of the child-thread. CSCI319 Chapter 3 Page: 17 of 40

18 Example: multiple thread The use of pthread_join in the previous example ensures that the value of r will be printed to the screen. However, since the two threads work at their own pace and hence, there is no guarantee that done will be printed after the value of r. Thread synchronization through mutexes or semaphores is needed to provide a guaranteed execution order. Thread synchronization is particularly important when several threads access the same resource. This is shown in an example as follows: CSCI319 Chapter 3 Page: 18 of 40

19 Example: multiple thread Another example illustrating the need for thread synchronization: int global = 0; void foo(int d){ global = * d * d / 4; } int main(){ int x, id; id = pthread_create(foo, 7); cout << global; pthread_join(id); return 1; } What will cout print? CSCI319 Chapter 3 Page: 19

20 Multithreaded Programming Advantages of multi-threaded programming: Parallelism Create threads on the fly Memory sharing allows fast communication between threads. Disadvantages of multi-threaded programming: Thread synchronization is difficult. Debugging, and algorithm development is more time consuming. We will learn thread synchronization during the lab classes. CSCI319 Chapter 3 Page: 20

21 Next: A look at Virtualization Reasons to consider virtualization in Distributed Systems: Software often outlives hardware In Grid computing: allows more readily implementation of security mechanisms, standardization of (virtual) hardware platform, etc. Replication, code migration, etc. is greatly simplified CSCI319 Chapter 3 Page: 21

22 Virtualization in Distributed Systems Virtualization is achieved as a layer which mimics hard or software interfaces. Example: Compare the general organization between a program, interface, and system in a non-virtualized system (a), with the organization of virtualizing the interface of system A on top of system B illustrated in (b). CSCI319 Chapter 3 Page: 22

23 Architectures of Virtual Machines (1) Note that interfaces between system components (soft- and hardware) can be at different levels: 1. An interface between the hardware and software consisting of machine instructions that can be invoked by any program. 2. An interface between the hardware and software, consisting of machine instructions that can be invoked only by privileged programs, such as an operating system. CSCI319 Chapter 3 Page: 23

24 Architectures of Virtual Machines (2) Interfaces at different levels (cont.) 3. An interface consisting of system calls as offered by an operating system. 4. An interface consisting of library calls generally forming what is known as an application programming interface (API). In many cases, the aforementioned system calls are hidden by an API. CSCI319 Chapter 3 Page: 24

25 Architectures of Virtual Machines (3) The various interfaces offered by computer systems can be illustrated as in the following:. CSCI319 Chapter 3 Page: 25

26 Architectures of Virtual Machines (4) Compare the previous with the interfaces in a virtual machine. Example 1: A process virtual machine called runtime system, with multiple instances of (application, runtime) combinations: CSCI319 Chapter 3 Page: 26

27 Architectures of Virtual Machines (5) Interfaces in a virtual machine (cont.). Example 2: A virtual machine monitor, with multiple instances of (applications, operating system) combinations: CSCI319 Chapter 3 Page: 27

28 Next: Anatomy of Clients and Servers 1.) The organization of clients 2.) The organization of Servers The requirements for client side processes differ vastly from server side processes. We will now look at some of those differences (i.e., communication and role). CSCI319 Chapter 3 Page: 28

29 Networked User Interfaces (1) In a DS a client needs to have means to interact with a (remote) server. This is generally achieved through the middleware. Hence, the middleware is a communication facilitator in DS providing application independent communication protocols. CSCI319 Chapter 3 Page: 29

30 Networked User Interfaces (2) It is rare to use application specific protocols in DS (can you explain why?). Though there are notable exceptions CSCI319 Chapter 3 Page: 30

31 Networked User Interfaces (3) The XWindows system * uses the later of the two communication approaches (application specific communication protocols). But why? Lets have a look at the working of an XWindows systems. Unlike MS-Windows, Xwindows has been designed from ground-up to work in a distributed computing environment. For example, Xwindows allows for a cost-efficient deployment in computing labs as is illustrated in the following: * Xwindows is often simply called after its communication protocol X CSCI319 Chapter 3 Page: 31

32 Example: The XWindow System The basic organization of the X Window System. Here, X is an application level protocol. This allows for X-applications and the X-kernel to not necessarily reside on the same machine. Thus, while X in itself is an application, it also acts as a middleware for X-applications and the X-kernel. CSCI319 Chapter 3 Page: 32

33 Anatomy of Clients and Servers (1) 1.) The organization of clients 2.) The organization of Servers CSCI319 Chapter 3 Page: 33

34 Anatomy of Clients and Servers (2) Servers side processes often need to handle several client requests concurrently. Thus, a main difference to client side processes is the number of requests that need to be handled. But one process can only process one (or very few) client requests concurrently. Hence, we must create additional processes to handle client requests as needed. But how can this be realized efficiently? Threads are a solution. But how to organize threads? Two popular strategies: daemons, and superservers CSCI319 Chapter 3 Page: 34

35 General Design Issues (1) An example: Client-to-server binding using a daemon. A fixed number of server threads is created at startup time by a parent process called deamon. Each client is then assigned to a dedicated and available server thread. CSCI319 Chapter 3 Page: 35

36 General Design Issues (2) Another solution: Client-to-server binding using a superserver. Here, server threads are created on demand, and then destroyed when the work is done. CSCI319 Chapter 3 Page: 36

37 Interactive slide (1) What is the main disadvantage of the deamon strategy and of the super server strategy? Deamon: If there are N server threads then no more than N clients can be served at any one time. Super server: Creating (and destroying) threads on demand creates an overhead (it is slower than the deamon strategy). Apache combines both approaches: There is a fixed number of idle threads created ahead of time. Therefore, there is always an idle thread ready to serve a new client. While clients are served, additional threads are created to maintain the number of idle threads. CSCI319 Chapter 3 Page: 37

38 Interactive slide (1) What is the main disadvantage of the deamon strategy and of the super server strategy? Deamon: If there are N server threads then no more than N clients can be served at any one time. Thus, there is a hard-limit which cannot be exceeded. Super server: Creating (and destroying) threads on demand creates an overhead (it is slower than the deamon strategy). Apache (web server) combines both approaches: There is a fixed number of idle threads created ahead of time. Therefore, there is always an idle thread ready to serve a new client. While clients are served, additional threads are created to maintain the number of idle threads. CSCI319 Chapter 3 Page: 38

39 Server Clusters (1) Threads are always created on the same machine on which the parent process resides. There is a limit to how much work a multi-threaded application can do within a single computing node (limited by the speed of the system itself; CPU, memory, etc). Multiple computing nodes are needed for large scale applications. For example, by engaging a cluster of computing nodes. It becomes necessary to dispatch an incoming task to one (or more) available computing nodes. CSCI319 Chapter 3 Page: 39

40 Server Clusters (2) An example illustrating a larger scale solution by using cluster: The general organization of a three-tiered server cluster. CSCI319 Chapter 3 Page: 40

41 Server Clusters (3) A closer look at how communication takes place: Server assignment through TCP handoff. The principle is illustrated as follows: CSCI319 Chapter 3 Page: 41

42 Interactive slide What is a TCP-handoff? What advantages does the TCP-handoff strategy have? CSCI319 Chapter 3 Page: 42

43 Interactive slide What is a TCP-handoff? Modify the content of the transport layer to mimic a response from another machine. Thus, the server can pretend that a response message was sent by the switch. What advantages does the TCP-handoff strategy have? Transparency: Client does not know which of the computing nodes created the response message. Client is made to believe that the switch responded. Scalability: Response messages do not need to be routed through the switch. CSCI319 Chapter 3 Page: 43

44 Server Clusters (4) Switch needs to decide which server is to handle the client request. Common dispatcher strategies: 1. Load balancing: Aim is that all nodes in the cluster are used equally. 2. Maximize resource utilization: Use one node until its capabilities are exhausted before dispatching tasks to another node. This effectively maximizes the number of idle nodes. 3. Route optimization: Assign a task to a node which is located closest to the client. CSCI319 Chapter 3 Page: 44

45 Processes tend to contain static code. Environmental changes often require the rebuilding of a process. A way to avoid such situation is through Code Migration This is commonly applied in DS. Some of the more wellknown ways to achieve this are: use of libraries, plugins. CSCI319 Chapter 3 Page: 45

46 Code migration Some advantages of code migration: Can allow the moving of a (possibly running) process from one machine to another (i.e. to achieve load balancing) Allows the utilization of a central code repository (for many servers) to improve system consistency. Can help to minimize development costs (i.e. through modularization, and code re-use) More flexible to environmental changes (i.e. new protocols, plugins, layout of forms, etc. can be changed on the fly ) Also: Allows code execution where data resides. CSCI319 Chapter 3 Page: 46

47 Migrating Code Example: The principle of dynamically configuring a client to communicate to a server. The client first fetches the necessary software, and then invokes the server. CSCI319 Chapter 3 Page: 47

48 Models for Code Migration Possible alternatives for code migration are as follows: CSCI319 Chapter 3 Page: 48

49 Models for Code Migration (2) Mobility of code refers to the level of binding between code and hardware. Therefore, weak mobility refers to code that has a weak binding to hardware. It does not mean that the movability of this code is weak. In weak mobility, it is possible to transfer only the code along with some initialization data. Example: Java applets. In strong mobility the execution segment needs to be transferred as well. Allows us to move a running process to another machine. Strong mobility is much more flexible than weak mobility but also much harder to implement. CSCI319 Chapter 3 Page: 49

50 Migration and Local Resources When migrating code, binding to resources may require consideration (i.e. access to a database, file, interface). A scheme to help identify suitable strategies to maintain such bindings has been proposed by Fugetta. CSCI319 Chapter 3 Page: 50

51 Interactive slide With reference to resource bindings when migrating code, what do the terms Unattached, Fastened, Fixed, by identifier, by value, by type refer to? CSCI319 Chapter 3 Page: 51

52 Interactive slide With reference to resource bindings when migrating code, what do the terms Unattached, Fastened, Fixed, by identifier, by value, by type refer to? Unattached: A resource is only attached to one machine of process. Fastened: File is part of a larger collection (i.e. web site, DB) Fixed: Bound to a machine, cannot be moved (i.e. gfx card) By identifier: I.e. a URL or an FTP file. By value: I.e. a library binding (path to library file may differ) By type: Type of a resource. I.e. Monitor, printer, keyboard. CSCI319 Chapter 3 Page: 52

53 Migration in Heterogeneous Systems Migration in heterogenous systems can be achieved in virtualized systems (i.e. moving an entire virtual machine) Three ways to handle migration (which can be combined): Pushing memory pages to the new machine and resending the ones that are later modified during the migration process. Stopping the current virtual machine; migrate memory, and start the new virtual machine. Letting the new virtual machine pull in new pages as needed, that is, let processes start on the new virtual machine immediately and copy memory pages on demand. CSCI319 Chapter 3 Page: 53

54 Summary on Processes Processes and threads Virtual Machines Client / Server design Distributed servers Code migration CSCI319 Chapter 3 Page: 54

DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S. TANENBAUM MAARTEN VAN STEEN. Chapter 3 Processes

DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S. TANENBAUM MAARTEN VAN STEEN Chapter 3 Processes Context Switching Processor context: The minimal collection of values stored in the