Processes
•Chapter 3
Processes
• Process: Program in execution.
• In DSs, more concepts come into consideration, eg.
Multi-treading, process migration, code migration,
• Threads: finer granular than processes, multiple
thread of control in a single process.
• Agents at the end of this chapter.
Threads
• Process :: Virtual processor
• Process table, used to manage virtual processors.
• Separation of processes domain in order to prevent
intervention!
• Concurrency transparency exists, but expensive!
• Threads are similar to processes, but no attempt to
provide such level of concurrency transparency
gaining performance.
• Thread context consists of nothing except CPU
switch + little tasks.
Threads-2
• Blocking of the whole process when a block system
call is executed; while we need to continue other
aspects of the task.
• Examples: An spreadsheet with two tasks, data
input and broadcasting of changes.
• Utilizing the processing power of more than one
CPU in a program.
• RPC with single-tread processes.
Thread Usage in Nondistributed Systems
• Context switching as the result of IPC
Threads-4
• Thread switching can be done in the user area, thus
no context switch!
• Threads are implemented in the form of a tread
package. Operatins include create, destroy +
operations for synchronization
• Two approaches
– Thread library and entirely in the user mode
• Cheap   Blocking of the process will block all!
– Support of kernel to be aware and to schedule them
• Expensive  no benefit of using threads!!
Thread Implementation
• Combining kernel-level lightweight processes and user-level threads.
• Several LWP in the context of a single process.
• Multithread application is constructed by creating threads, and assign
each tread to a LWP
• Each LWP finds a running thread and Context switch of LWPs are
done in the user space
Multithreaded Clients & Servers
• Browsing a web page containing several links
• Paralled downloading of pages through
multithreading to replicas of a web-server, when thr
server is the bottleneck.
• Main usage in DSs is for serevrs, for parallelism and
higher performance.
Multithreaded Servers (1)
• A multithreaded server organized in a dispatcher/worker model.
Multithreaded Servers (2)
Model
Characteristics
Threads
Parallelism, blocking system calls
Single-threaded process
No parallelism, blocking system calls
Finite-state machine
Parallelism, nonblocking system calls
Using msgs.
• Three ways to construct a server.
The X-Window System
• The basic organization of the X Window System
Client-Side Software for Distribution Transparency
• A possible approach to transparent replication of a remote
object using a client-side solution.
Servers
• Iterative Servers
• Concurrent Servers, through threads or even forking new
processes.
• Next slide ….
• Staeless Server: does not keep info on the state of its clients; can
change its own state regardless of the clients:: Web Server
• Statefull Server: File Server
• Object Server: A server to support distributed objects.
Servers: General Design Issues
a)
b)
Client-to-server binding using a daemon as in DCE
Client-to-server binding using a superserver as in UNIX
3.7
Object Adapter (1)
• Alternatives for Invoking
Objects
– Only one way to invoke
…Inflexible
– Diffeerent policies
• Making a transient object at the
first invocation
• Each object is located in a memory
segment of its own.
• Activation Policy: How to invoke
an object?
• Organization of an object server
supporting different activation policies.
• Object Adapter: Group objects per policy
Object Adapter (2)
/* Definitions needed by caller of adapter and adapter */
#define TRUE
#define MAX_DATA 65536
/* Definition of general message format */
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);
void unrigester_object (long object)id);
void invoke_adapter (message *request);
/* register an object */
/* unrigester an object */
/* call the adapter */
• The header.h file used by the adapter and any
program that calls an adapter.
Object Adapter (3)
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 (4)
• The main part of an
adapter that implements a
thread-per-object policy.
Code Migration
• Till now, passing data as parameters to a remote
process/thread/object.
• Sometimes, it is needed to pass a program, EVEN
while it is being run.
• Code migration in
– Homogeneous systems
– Heterogeneous systems
• Security issues are discussed in section 8.
Motivation
• Getting performance through migrating processes
from heavily-loaded machines to lightly-loaded ones
• Load distribution is a very important player!
• Optimizing computing capacity is less an issue than
minimizing communication!
• Scenario: A process handling a large quantity of data
in a client-server architecture. Which part should be
migrated? Data-Centric or UI centric?
• Flexibility is another motivation.
Reasons for Migrating Code
• 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
• Alternatives for code migration.
• Assuming a process has 3 segments: code, resource,
execution
Mobility
• Weak: transfer code + initialization data. Program
always starts from ZERO  simple; target machine
should be able to execute the code:: Java Applet
• Strong: the execution segment can also be
transferred  The running process should be
suspended, transferred, and resumed:: D’Agents
• Initiator: Sender (sending to a compute server, or a query
to the search engine :: server should know all its clients) or
Receiver (Java Applet; can be done anonymously)
Migration and Local Resources
• Resource segment cannot be transferred simply!
• Example: binding to a TCP port! Reference to a file.
• 3 types of process-to-resource bindings:
– by identifier  process requires the referenced resource,
nothing else (a URL)
– by value  another resource can be used, e.g. general
libraries in C or Java.
– By type  references to monitor, printer, ..
• Unattached resources, Fastened resources (local DBSs), and
Fixed resources (bound to local resources)
Migration and Local Resources
• Actions to be taken with respect to the references to local resources when
migrating code to another machine.
Resource-to machine binding
Process-to- By identifier
resource By value
binding 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)
GR: Establish a global system wide reference;
MV: Move the resource;
CP: Copy the value of resource;
RB: Rebind process to locally available resource
Migration in Heterogeneous Systems
• Till now, it is assumed that the code can be run there
• In the case of weak mobility, new compilation!
• In the case of strong mobility, migration of the
execution segment.  at least we need the same
H/W architecture and the same OS.
• Execution segment includes: data (private to the process),
current stack (temp data, platform-dependent register values!) & PC.
• A solution for procedural languages in the next
slide: Restricting the migration on calling a
subroutine
Migration in Heterogeneous Systems
• The principle of maintaining a migration stack to support migration
of an execution segment in a heterogeneous environment
3-15
D'Agents
• An agent in D’Agents is a program that can migrate.
• Programs can be written in any language that can be
run in the target machine (Tcl, Java, Scheme)
• Mobility
– Sender-initiated weak, separate process, through agent_submit command
• Next slide
– Process migration strong, through agent_jump command, the caller process is
suspended; all segments (code, resource, execution) are marshaled and sent for
the destination. A new process is initiated and resume execution after the
agent_jump call. Now the suspended process exit.
– Cloning strong
Overview of Code Migration in D'Agents (1)
A simple example of a Tcl agent in D'Agents submitting a script to a remote
machine (adapted from [gray.r95])
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
agent_submit $machine –procs factorial –vars number –script {factorial $number }
agent_receive …
# receive the results (left unspecified for simplicity)
Overview of Code Migration in D'Agents (2)
An example of a Tcl agent in D'Agents migrating to different machines
where it executes the UNIX who command (adapted from [gray.r95])
all_users $machines
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.
agent_submit $this_machine –procs all_users
-vars machines
-script { all_users $machines }
agent_receive …
#receive the results (left unspecified for simplicity)
Implementation Issues (1)
• The architecture of the D'Agents system.
Language independent core
Start and end an agent,
Various migration operations
Messaging
Agent Mngmnt,
Authentication,
Inter-agent Communication
Implementation Issues (2)
• The parts comprising the state of an agent in D'Agents.
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
Software Agents
• Independent views of execution are concluded in Software
Agents.
• Autonomous units capable of performing a task in
collaboration with other, possibly remote agents.
• Collaborative agents: autonomy and cooperation.
• Mobile agents: Ability to move between different
machines.
• Interface agent: assist end-user in the use of one or more
applications.
• Information agent: manage information from different
sources
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
• Some important properties by which different types of
agents can be distinguished.
Agent Technology
The general model of an agent platform (adapted from [FIPA 98-mgt]).
ACC: Agent Communication Channel, which provides the abstraction of a
reliable/ordered/…. channel.
Agent Communication Languages (0)
• Communication between agents in the application
level.
• A strict separation between the purpose of a message
& its content.
• Purposes of the message in the next slide (FIPA).
Agent Communication Languages (1)
• Examples of different message types in the FIPA ACL [fipa98-acl], giving the
purpose of a message, along with the description of the actual message content.
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 give 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
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
Prolog
Ontology
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.