Processes Chapter 3 Table of Contents

Processes Chapter 3

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

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.

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. – ……

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

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).

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

Threads in Nondistributed Systems Context switching as the result of IPC

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

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

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.

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

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

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

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

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

Three ways to construct a server Model Characteristics Threads Parallelism, blocking system calls Single-threaded process No parallelism, blocking system calls Finite-state machine Parallelism, nonblocking system calls • Blocking calls: Easy • Parallelism: Efficient, high performance

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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.

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

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

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

Models for Code Migration Alternatives for code migration.

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?

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, …

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

Migration and Local Resources Resource-to machine binding Unattached Process-to- By identifier resource By value binding By type Fastened Fixed MV (or GR) CP ( or MV, GR) RB (or GR, CP) GR (or MV) GR (or CP) RB (or GR, CP) GR GR RB (or GR) GR: Establish a global systemwide reference MV: Move the resource CP: Copy the value of the resource RB: Rebind process to locally available resource Actions to be taken with respect to the references to local resources when migrating code to another machine.

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

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

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

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

Homework #1 due 11/26, 2 pm • Problem 3 in chapter 3, page 180 – In the text, we described a multithreaded file server, showing why it is better than a singlethreaded server and a finite-state machine server. Are there any circumstances in which a singlethreaded 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?

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