processes chapter 3. table of contents multithreading clients and servers code migration software...
TRANSCRIPT
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 技术曹 春 博士
南大软件新技术国家重点实验室