1. Processes Chapter 3

2. Table of Contents Multithreading Clients and Servers Code Migration Software Agents (special topic)

3. 3.1 Multithreading Process vs. Thread –A process is often defined as a program in execution. –A thread is a sequence of instructions that can be executed in parallel with other threads. –Threads are like lightweight processes.

4. 3.1 Multithreading Process vs. Thread –Multiple threads within a single process share the state information, memory and other resources directly, but they are able to execute independently –Threads collaborate with each other -- processes compete. –……

5. 3.1 Multithreading Why Multithreading? –Allows to perform more than one task at a time. –Increases the performance of programs.

6. 3.1 Multithreading When Multithreading? –A multiprocessor computer works by using the multiple processors to handle threads simultaneously (multiprocessing). –A program that spends a great deal of time waiting for outside events (time slicing).

7. Threads in Nondistributed Systems Interprocess communication (IPC) –Pipes, Message queues, Shared memory segments, Semaphore, Signal –Heavy context switching user -> kernel mode switch in kernel kernel -> user mode

8. Threads in Nondistributed Systems Context switching as the result of IPC

9. Threads in Nondistributed Systems Multithreads (in a process) –Communicate by using shared data –User space switching mostly –Don’t bother the kernel => Efficient

10. Thread Implementation Combining kernel-level lightweight processes and user-level threads.

11. Threads in Distributed Systems The usage of threads –allows blocking system calls without blocking the entire process in which the thread is running. –Multiple threads maintain multiple logical connections at the same time.

12. Threads in Distributed Systems Multithreaded Clients –Example: web browser Main HTML file More connections simultaneously for images, … –Web servers are replicated Request is forwarded Connections to replicas Transfer data in parallel

13. Threads in Distributed Systems Multithreaded Servers –Single-threaded process –Finite-state machine –Threads

14. Single-threaded process The server –Receive a request –Execute it (either locally or remotely) Loop –Reply the result No other request is allowed when handling the current request. Simple, easy, … but inefficient

15. Finite-state machine The server –Received messages are recorded in a table –Fetch a message new work? Start it Result of previous work? Reply it Nonblocking calls to send and receive

16. Threads The server –Receive a request –Dispatch to a free worker thread A multithreaded server organized in a dispatcher/worker model.

17. Three ways to construct a server Blocking calls: Easy Parallelism: Efficient, high performance ModelCharacteristics ThreadsParallelism, blocking system calls Single-threaded processNo parallelism, blocking system calls Finite-state machineParallelism, nonblocking system calls

18. 3.2 Clients Task –Interface: interact with a human user and a remote server. –Partial computation –Implementation of Transparency –……

19. Distribution Transparency A client should not be aware that it is communicating with remote processes.

20. Distribution Transparency Different forms of transparency in a distributed system. (from chapter one) TransparencyDescription Access Hide differences in data representation and how a resource is accessed LocationHide where a resource is located MigrationHide that a resource may move to another location Relocation Hide that a resource may be moved to another location while in use ReplicationHide that a resource is replicated Concurrency Hide that a resource may be shared by several competitive users FailureHide the failure and recovery of a resource Persistence Hide whether a (software) resource is in memory or on disk

21. Distribution Transparency (1) Access transparency –A client stub is generated from an interface definition of what the server has to offer. –The client stub: provides the same interface as available at the server. handles the communication between two sides.

22. Distribution Transparency (2) Location | Migration | Relocation transparency –Naming system –Bind and rebind the server –Temporarily out of service (maybe)

23. Distribution Transparency (3) Replication transparency –Forward a request to each replica –Collect all responses –Pick a single return value Safe but inefficient

24. Client-Side Software for Distribution Transparency A possible approach to transparent replication of a remote object using a client-side solution.

25. Distribution Transparency (4) Failure transparency –Repeat to build the connection –Try another server –Pick the data from its own cache

26. Distribution Transparency (5) Concurrency transparency –Server’s job mostly –Intermediate servers Persistence Transparency –Server’s job totally

27. 3.3 Servers Definition –A server is a process implementing a specific service on behalf of a collection of clients Organization –Waits for an incoming request from a client –Handle the request –Reply the result to the client

28. 3.3 Servers Type –Iterative server Handle the request by itself –Concurrent server Forward to other available process (or thread) Fork a new process (or thread) to handle the request

29. 3.3 Servers –Stateless server Does not keep information on the state of its clients, for example, a web server. –Stateful server Maintain information on its clients Better services, better performance Drawback: recover the client information sometimes –Hybrid solution cookie

30. 3.3 Servers Endpoint or port –Preassign endpoint for well-known services globally: FTP:21, HTTP:80 –(Server, port) pair in a special daemon –Superserver Listen to some endpoints Fork a server process to handle the incoming request

31. Servers: General Design Issues 3.7 a)Client-to-server binding using a daemon as in DCE b)Client-to-server binding using a superserver as in UNIX

32. 3.3 Servers Special Case: Object servers –Definition: A server to support (contain) distributed objects No service directly from the server, but implemented by the objects in the server Server’s job: invoke local objects based on incoming requests Positive: easy to change services by just updating objects

33. 3.3 Servers –Object Data: represents the state Code: method implementation –Object Adapter Activation policies: the way how to invoke an object Object adapter: a mechanism to group objects based on the above policy and dispatch requests to different objects

34. Object Adapter (Omitted) Organization of an object server supporting different activation policies.

35. 3.4 Code Migration What is code migration? –In a distributed system, programs (code) can be transferred among different machines, sometimes even while they are be executed. Why code migration? –Performance, always Why not code migration? –Security, always

36. Reasons for Migrating Code Basic idea of process migration –Overall system performance can be improved if processes are moved from heavily-loaded to lightly-loaded machines. Related stuff –Communication cost –Heterogeneity –Security –Error recovery

37. Examples Clients => Servers –A program in the client containing a lot of query operations for the database residing in a server. Servers => Clients –Network installation: OS… –Java applets A tradeoff between the cost of communication and the execution of program

38. Examples The principle of dynamically configuring a client to communicate to a server. The client first fetches the necessary software, and then invokes the server. Code migrated from the third party

39. Models for Code Migration Fugetta’s framework (1998) –Code segment Instructions of a program –Resource segment References to external resources: printer, devices, other processes, … –Execution segment Current execution state of a process: private data, stack, program counter.

40. Models for Code Migration Mobility –Weak mobility: only transfer the code segment as well as some initialization data Transferred programs are always started from the very beginning. Simple –Strong mobility: transfer not only the code segment, but also the execution segment Running process is stopped => move to other machine => resume execution Flexible but hard to be implemented

41. Models for Code Migration Initiator –Sender-initiated: a migration is initiated from a the machine where the code currently resides or is being executed. –Receiver-initiated: the target machine initiates the migration, for example, Java applet.

42. Models for Code Migration Migration in client/server model –Client => Server Access to the server’s resource security problem –Server => Client Improve the client-side performance

43. Models for Code Migration How to execute the migrated code in weak mobility? –By target process Avoid communication, efficient Once again, security problem –Start a new process IPC

44. Models for Code Migration How to execute the migrated code in strong mobility? –Migrate process –Clone process In UNIX, remote cloning is done by fork off a child process and let it run in the remote machine. Simple

45. Models for Code Migration Alternatives for code migration.

46. Models for Code Migration Migration and Local resource –The resource segment in Fugetta’s framework –How to bind a resource to a process? –What kind of resources a process may use?

47. Models for Code Migration Process-resource Binding –By identifier URL to a server by its internet address reference to local communication endpoint –By value Library code –By type Monitors, printers, …

48. Models for Code Migration Resource-machine binding –Unattached Typically (data) files associated with the migrated program Easy to move –Fastened Local databases and complete web sites Reluctant to move –Fixed Local devices, local communication endpoint Impossible to move

49. Migration and Local Resources Actions to be taken with respect to the references to local resources when migrating code to another machine. UnattachedFastenedFixed 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 RB (or GR) Resource-to machine binding Process-to- resource binding GR: Establish a global systemwide reference MV: Move the resource CP: Copy the value of the resource RB: Rebind process to locally available resource

50. Migration in Heterogeneous Systems So far, we always assume that the migrated code can be easily executed at the target machine. Homogeneous system: same architecture, same data representation, same compiler, same platform… Heterogeneous system

51. Migration in Heterogeneous Systems Weak mobility –Transfer the code –Compile it in the target machine –Execute it Strong mobility –Nightmare –How to deal with the platform-dependent runtime information? –Migration stack solution: difficult with more restriction

52. Migration in Heterogeneous Systems The principle of maintaining a migration stack to support migration of an execution segment in a heterogeneous environment 3-15

53. Migration in Heterogeneous Systems Virtual machine: a charming solution –Source code in scripting languages –Intermediate machine-independent code generated by compilers Java Bytecode JVM

54. Homework #1 due 11/26, 2pm Problem 3 in chapter 3, page 180 –In the text, we described a multithreaded file server, showing why it is better than a single- threaded server and a finite-state machine server. Are there any circumstances in which a single- threaded server might be better? Give an example. Problem 14 in chapter 3, page 181 –Is a server that maintains a TCP/IP connection to a client stateful or stateless? In general, what’s the benefit of code migration? What’s the difficulty of doing so?

55. Invited Talk 软件 agent 技术 曹 春 博士 南大软件新技术国家重点实验室