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) Loop– Reply the result

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

• Blocking calls: Easy

• Parallelism: Efficient, high performance

Model Characteristics

Threads Parallelism, blocking system calls

Single-threaded process No parallelism, blocking system calls

Finite-state machine Parallelism, nonblocking system calls

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

Different forms of transparency in a distributed system.

(from chapter one)

Transparency Description

AccessHide 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

RelocationHide that a resource may be moved to another location while in use

Replication Hide that a resource is replicated

ConcurrencyHide that a resource may be shared by several competitive users

Failure Hide the failure and recovery of a resource

PersistenceHide whether a (software) resource is in memory or on disk

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) Client-to-server binding using a daemon as in DCEb) 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

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

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

Actions to be taken with respect to the references to local resources when migrating code to another machine.

Unattached Fastened Fixed

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

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

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

The principle of maintaining a migration stack to support migration of an execution segment in a heterogeneous environment

3-15

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

Invited Talk

软件 agent 技术曹 春 博士

南大软件新技术国家重点实验室