Processes
Chapter 3
Thread Usage in Nondistributed Systems
Context switching as the result of IPC
– Process: a running program (mgmt. unit of OS)
– Thread: execution unit within a process
– Switching:
• Processes: expensive (CPU context, MMU, TLB, …)
• Threads: cheap (almost only CPU context)
Thread Design Issues
– User-level threads:
+: create, destroy, switching very cheap, because without OS.
-: blocking system calls (e.g. communication) would block all threads.
 parallelism is restricted
– Kernel-level threads:
+: kernel can do context switching when blocking system calls are used.
 more parallelism
-: create, destroy, switching are expensive (switches to kernel mode necessary).
– Hybrid solution:
Seems to be the best one.
Use of user-level threads (thread package).
Use of kernel-level threads so-called light-weight processes (LWPs).
Thread Implementation
Combining kernel-level lightweight processes and user-level threads.
Multithreaded Clients (1)
– Example: WWW Browser
Thread 1: get text
Thread 2: get image
Thread 3: get banner
…
 Better responsiveness, but user may notice parallelism.
– Multiple connections to server:
If server is replicated (i.e. horizontal distribution), different connections
correspond to different server instances.
 more parallelism
Multithreaded Servers (1)
A multithreaded server organized in a dispatcher/worker model.
Multithreaded Servers (2)
Model
Characteristics
Threads (multi-threaded process)
Parallelism, blocking system calls
Single-threaded process
No parallelism, blocking system calls
Finite-state machine
Parallelism, nonblocking system calls
Three ways to construct a server.
Finite-state machine (rather intricate):
– Only one thread (that simulates multiple ones)
– Loop:
• Get next message.
• Do some computation if needed.
• Send asynchronous message(s) to device(s) (e.g. disk) – no blocking on I/O.
• Go to first step (and receive next message, which may be from disk or from
client).
Clients: User Interface
The X-Window System
The basic organization of the X Window System
Client-Side Software for Distribution Transparency
–
–
–
–
–
Access transparency: IDL-based stubs
Relocation/migration transparency: rebind within middleware (stub/proxy)
Replication transparency: see below
Failure transparency: time redundancy, use of caches as in browsers, …
Concurrency/persistence transparency: rather at server or intermediate server
(transaction monitors manage concurrent transactions)
Servers: General Design Issues (1)
3.7
name to port mapping
listens to all relevant ports
a)
b)
Client-to-server binding using a daemon as in DCE
Client-to-server binding using a superserver as in UNIX (Inetd server)
Servers: General Design Issues (2)
– Handling interrupts:
– Out-of-band data: highest priority (supported in TCP)
– Server is interrupted (e.g. Unix signal)
– Stateful/stateless server:
– Stateful: Server holds information about clients. For example, which client
has currently opened a file for writing.
Recovery is needed after crash
May enhance performance
– Stateless: no information about clients is held
No recovery after crashes
Less performance
– Sometimes servers keep information about client behavior
Cookies (web server information on user’s favorite pages kept at client side)
Problem: privacy
Object Servers: Object Invocation
– Object server:
– Server that invokes local objects on behalf of client requests
– It does not implement a service, objects implement services
– Only a room where objects live
– Issues:
– Transient objects:
In-memory ones that live as long as server lives (or shorter)
Create object at first invocation and delete it when no clients are bound
to it : +: minimizes resources, -: some invocations may be slow
Create all transient objects at once
– Code/data sharing:
All objects are separated (e.g. different segments)
+: promotes security
But code sharing may be very useful for persistent objects (e.g. code of
class in memory and data of different objects on disk)
– Threading:
On demand / pool
Per invocation (sync needed) / per object (no sync needed)
Object Adapter (1)
• Object adapter (also called object wrapper):
Software (part of middleware) that implements a specific
activation policy.
• Activation policy: e.g. per object / per invocation thread.
• Main idea: objects should be kept simple and should no know how
they are invoked (+: reliability).
• Object adapters are generic (independent from object)
• They communicate rather with the skeleton/stub of the object and
not with the object itself.
• Objects are rather passive until invocated by adapter.
• Multiple object adapters on same machine with different activation
policies possible and desirable for reasons of flexibility.
Object Adapter (2)
Organization of an
object server
supporting
different activation
policies.
Policy 1
Policy 2
Object 2.1
Object 1.1
Object 2.2
Object Adapter (3)
/* Definitions needed by caller of adapter and adapter */
#define TRUE
#define MAX_DATA 65536
/* Definition of general message format: adapter/client*/
struct message {
long source
/* senders identity */
long object_id;
/* identifier for the requested object */
long method_id;
/* identifier for the requested method */
unsigned size;
/* total bytes in list of parameters */
char **data;
/* parameters as sequence of bytes */
};
/* General definition of operation to be called at skeleton of object */
typedef void (*METHOD_CALL)(unsigned, char* unsigned*, char**);
long register_object (METHOD_CALL call); /* register an object: from stub */
void unrigester_object (long object)id);
/* unrigester an object: from stub */
void invoke_adapter (message *request);
/* call the adapter: from deMUX*/
The header.h file used by the adapter and any program that
calls an adapter.
Object Adapter (4)
typedef struct thread THREAD;
/* hidden definition of a thread */
thread *CREATE_THREAD (void (*body)(long tid), long thread_id);
/* Create a thread by giving a pointer to a function that defines the actual */
/* behavior of the thread, along with a thread identifier */
void get_msg (unsigned *size, char **data);
void put_msg(THREAD *receiver, unsigned size, char **data);
/* Calling get_msg blocks the thread until of a message has been put into its */
/* associated buffer. Putting a message in a thread's buffer is a nonblocking */
/* operation. */
The thread.h file used by the adapter for using threads.
Object Adapter (5)
The main part of
an adapter that
Implements a
thread-per-object
policy.
Adapter thread
Demultiplexer
thread
Code Migration
• Migration: shift entity (process, application, …) from A to B.
• Why?:
- gain more performance: utilize lightly-loaded nodes or exploit parallelism
(e.g. search in the Web).
- enhance reliability/availability: separate faulty and well-behaved applications
(rather new).
- be more flexible (see next slide)
• Load: cumulative CPU requirements of ready-to-run processes, length of readyto-run queue, utilization, …
• Goals (related to performance): a) minimize computation time, b) minimize
advent of communication (important in distributed systems)
• Examples:
- client code is better executed at server, if too many data are needed to obtain
some result.
- server code is better executed at client, if too many user interactions are needed
prior to actual processing.
Dynamic Client Configuration
(enhances flexibility)
e.g. protocol implementation
(language that server speaks)
The principle of dynamically configuring a client to communicate to a server. The
client first fetches the necessary software, and then invokes the server.
 Issue: security
Models for Code Migration (1)
•
•
•
•
•
Mobility: refers to the fact that an entity can be migrated.
Weak mobility: only code part of entity (with some initialization data) is migrated. Entity
can only begin computation at target node.
 Java applets
a) code executed in same process (less secure but efficient, e.g. applets are executed in
browsers)
b) code executed in different process (more secure, but resources like files are not
protected, and less efficient)
Strong mobility: both code and whole state of entity (data, CPU registers, etc.) are
migrated.
 the entity (e.g. process) can continue computation on target node from where it
has been stopped.
 example: D’Agent
 remote cloning: copy of entity on target machine, but original remains at sender
machine (e.g. Unix fork and continue on different machine).
Sender-initiated: initiative of migration is taken at sender side (e.g. upload code to a
server)
Receiver-initiated: initiative of migration is taken at receiver side (e.g. Java applets).
Models for Code Migration (2)
Alternatives for code migration.
Migration and Local Resources (1)
•
•
•
•
What to do with resources after a process has been migrated?
Resources: monitors, files, ports, libraries, …
 Resource bindings may change after migration (unlike code and state)
Process-to-resource bindings:
• Binding by identifier: Process needs exactly the resource used before migration.
 new resource is equal old resource, e.g. local port
• Binding by value: Process needs the value of the resource used before migration.
 new resource is equivalent to old resource, e.g. programming library
• Binding by type: Process needs a resource of a specific type.
 new and old resources have same type, e.g. monitors, printer, …
• Resource-to-machine bindings:
• Unattached resources: Not bound to a specific machine, e.g. unshared file
• Fastened resources: In principle independent of any machines, but de facto (e.g.
enormous moving overhead) bound to a machine, e.g. Web database
• Fixed resources: bound to a specific machine, e.g. devices
Migration and Local Resources (2)
Resource-to machine binding
Process-toresource
binding
By identifier
By value
By type
Unattached
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)
MV: move resource
GR: use global reference
CP: copy resource
RB: rebind to (local) resource
Actions to be taken with respect to the references to local
resources when migrating code to another machine.
 Establishing global references may always solve the problem of resource
bindings after migration, however it may introduce more overhead (e.g.
communication, reconfiguring owners of global reference).
Migration in Heterogeneous Systems
3-15
The principle of maintaining a migration stack to support migration of an execution
segment in a heterogeneous environment
State-of-the-art: Use of a virtual machine (e.g. Java)
 relies on only one language
Overview of Code Migration in D'Agents (1)
proc factorial n {
if ($n  1) { return 1; }
expr $n * [ factorial [expr $n – 1] ]
# fac(1) = 1
# fac(n) = n * fac(n – 1)
}
set number …
# tells which factorial to compute
set machine …
# identify the target machine
Main Program
agent_submit $machine –procs factorial –vars number –script {factorial $number }
agent_receive …
# receive the results (left unspecified for simplicity)
A simple example of a Tcl agent in D'Agents submitting a
script to a remote machine
agent_submit: sender-initiated weak migration (with separate process at
receiver side)
Overview of Code Migration in D'Agents (2)
proc all_users machines {
set list ""
foreach m $machines {
agent_jump $m
set users [exec who]
append list $users
}
return $list
}
set machines …
set this_machine
# Create an initially empty list
# Consider all hosts in the set of given machines
# Jump to each host
# Execute the who command
# Append the results to the list
# Return the complete list when done
# Initialize the set of machines to jump to
# Set to the host that starts the agent
# Create a migrating agent by submitting the script to this machine, from where
# it will jump to all the others in $machines.
Main
agent_submit $this_machine –procs all_users
-vars machines
-script { all_users $machines }
agent_receive …
Program
#receive the results (left unspecified for simplicity)
An example of a Tel agent in D'Agents migrating to different
machines where it executes the UNIX who command
agent_jump: sender-initiated strong migration
agent_fork: sender-initiated remote cloning
Implementation Issues (1)
Agent start/end, migration, agent-level
communication
Agent mgmt (e.g. Ids), authentication,
communication
The architecture of the D'Agents system.
Implementation Issues (2)
Status
Description
Global interpreter variables
Variables needed by the interpreter of an agent
Global system variables
Return codes, error codes, error strings, etc.
Global program variables
User-defined global variables in a program
Procedure definitions
Definitions of scripts to be executed by an agent
Stack of commands
Stack of commands currently being executed
Stack of call frames
Stack of activation records, one for each running
command
The parts comprising the state of an agent in D'Agents.
Software Agents in Distributed Systems
Property
Common to
all agents?
Description
Autonomous
Yes
Can act on its own
Reactive
Yes
Responds timely to changes in its environment
Proactive
Yes
Initiates actions that affects its environment
Communicative
Yes
Can exchange information with users and other
agents
Continuous
No
Has a relatively long lifespan
Mobile
No
Can migrate from one site to another
Adaptive
No
Capable of learning
Important properties by which different types of agents can be
distinguished.
Other functional properties:
Interface agents: personal agents that assist users in the use of applications (usually
learning/intelligent agents)
Information agents: process information from different sources (usually mobile agents that
roam the network)
Agent Technology
Agent communication
channel
Create/delete agent, end points
mapping, …
What do other agents offer?
The general model of an agent platform (FIPA model).
FIPA: Foundation for Intelligent Physical Agents
Some Agent Applications
•
•
•
•
Searching (e.g. in the Web):
 Enhances parallelism.
 Mobility is asset.
E-Commerce:
 Walk in the network to find best offers.
 Pay at seller side.
 Issue: security.
Network management:
 Performance, fault, configuration mgmt, and other functions.
 Cooperation is asset: networks may span over different organizational domains.
 Examples:
a) Construct new complex services in cooperation with other agents (on-the-fly!).
b) Solve performance reductions or fault situations by cooperating with agents in other
domains.
Computer-assisted learning:
 Intelligence is asset: agent should be able to adapt to student’s knowledge.
 Relevant in distributed systems, if (distributed) agents cooperate in doing their work.
Agent Communication Languages (1)
Message purpose
Description
Message Content
INFORM
Inform that a given proposition is true
Proposition
QUERY-IF
Query whether a given proposition is true
Proposition
QUERY-REF
Query for a given object
Expression
CFP
Ask for a proposal
Proposal specifics
PROPOSE
Provide a proposal
Proposal
ACCEPT-PROPOSAL
Tell that a given proposal is accepted
Proposal ID
REJECT-PROPOSAL
Tell that a given proposal is rejected
Proposal ID
REQUEST
Request that an action be performed
Action specification
SUBSCRIBE
Subscribe to an information source
Reference to
source
Examples of different message types in the FIPA ACL giving the purpose of a message,
along with the description of the actual message content.
Agent Communication Languages (2)
Field
Value
Purpose
INFORM
Sender
max@http://fanclub-beatrix.royalty-spotters.nl:7239
Receiver
elke@iiop://royalty-watcher.uk:5623
Language (syntax)
Prolog
Ontology (semantics)
genealogy
Content
female(beatrix), parent(beatrix, juliana, bernhard)
A simple example of a FIPA ACL message sent between two agents
using Prolog to express genealogy information.