Processes

Chapter 3

Processes

• Topics discussed in this chapter:– Threads improve performance.

• In distributed systems threads allow clients and servers to be constructed such that communication and local processing can overlap.

– Clients: various GUI systems.– Servers: object servers– Code migration can help achieve scalability and

dynamically configure clients and servers.– Software agents are a type of process which

attempt to reach a common goal.

Introduction to Threads• Basic idea: An operating system creates virtual

processors in software on top of physical processors.– A processor provides the capability of executing a series of

instructions.– A process is a program in execution.

• A software processor in whose context one or more threads may be executed. Executing a thread means executing a series of instructions in the context of that thread.

– A thread is the execution of a part of a program. • A thread maintains the minimal information to allow a CPU to be

shared by several threads. • A thread context consists of the CPU context and the information

for the thread.• Saving a thread context implies stopping the current execution and

saving all the data needed to continue the execution at a later stage.

Context Switching

• Processor context: The minimal collection of values stored in the registers of a processor used for the execution of a series of instructions (e.g., stack pointer, addressing registers, program counter).

• Process context: The minimal collection of values stored in registers and memory, used for the execution of a series of threads (i.e., thread context, but now also at least MMU register values).

• Thread context: The minimal collection of values stored in registers and memory, used for the execution of a series of instructions (i.e., processor context, state).

Thread Usage in Nondistributed Systems

Context switching as the result of IPC

Context Switching

• Observation 1: Threads share the same address space. Thread context switching can be done entirely independent of the operating system.

• Observation 2: Process switching is generally more expensive as it involves getting the OS in the loop, i.e., trapping to the kernel.

• Observation 3: Creating and destroying threads is much cheaper than doing so for processes.

Threads and Operating Systems • Main issue: Should an OS kernel provide threads,

or should they be implemented as user-level packages?

• User-space solution:– We'll have nothing to do with the kernel, so all operations

can be completely handled within a single process. Implementations can be extremely efficient.

– All services provided by the kernel are done on behalf of the process in which a thread resides. If the kernel decides to block a thread, the entire process will be blocked. Requires messy solutions.

– In practice we want to use threads when there are lots of external events: threads block on a per-event basis If the kernel can't distinguish threads, how can it support signaling events to them.

Threads and Operating Systems • Kernel solution: The whole idea is to have the kernel

contain the implementation of a thread package. This does mean that all operations return as system calls.

• Operations that block a thread are no longer a problem: the kernel schedules another available thread within the same process.

• Handling external events is simple: the kernel (which catches all events) schedules the thread associated with the event.

• The big problem is the loss of efficiency due to the fact that each thread operation requires a trap to the kernel.

• Conclusion: Try to mix user-level and kernel-level threads into a single concept.

Solaris Threads • Basic idea: Introduce a two-level threading approach: user-level

processes and light-weight processes (LWP) that can execute user-level threads in the kernel.

• When a user-level thread does a system call, the LWP that is executing that thread blocks. The thread remains bound to the LWP.

• The kernel can simply schedule another LWP having a runnable thread bound to it. Note that this thread can switch to any other runnable thread currently in user space.

• When a thread calls a blocking user-level operation, we can simply do a context switch to a runnable thread, which is then bound to the same LWP.

• When there are no threads to schedule, a LWP may remain idle, and may even be removed (destroyed) by the kernel.

Thread Implementation

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

Threads and Distributed Systems • Multithreaded clients: To establish a high degree of

distribution transparency, distributed systems need hiding network latencies (so that the user is not knowing there is a interprocess communication across a wide-area network).

• Example: Multithreaded Web Client– A Web browser scans an incoming HTML page, and finds that more

files need to be fetched.– Each file is fetched by a separate thread, each doing a (blocking) HTTP

request.– As files come in, the browser displays them.

• Example: Multiple RPCs– A client does several RPCs at the same time, each one by a different

thread.– It then waits until all results have been returned.– Note: If RPCs are to different servers, we may have a linear speed-up

compared to doing RPCs one after the other.

Threads and Distributed Systems • Multithreaded servers: Main issues are improving

performance and better programming structure.• Improve performance

– Starting a thread to handle an incoming request is much cheaper than starting a new process.

– Having a single-threaded server prohibits simply scaling the server to a multiprocessor system.

– Servers hide network latency by reacting to next request while previous one is being replied.

• Better programming structure– Most servers have high I/O demands. Using simple, well-

understood blocking calls simplifies the overall structure. – Multithreaded programs tend to be smaller and easier to

understand due to simplified flow of control.

Multithreaded Servers

A multithreaded server organized in a dispatcher/worker model.

Multithreaded Servers

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

Clients - User Interfaces

• Essence: – A major task of most clients is to interact with a

human user and a remote server.– A major part of client-side software is focused on

(graphical) user interfaces.

• The X Window System is used to control bit-mapped terminals.

The X Window System• The heart of the system is formed by the X kernel.

It contains all the terminal-specific device drivers.• The X kernel interface for controlling the screen is

made available to applications in the Xlib library.• There are two types of X applications: ordinary

applications and window managers.• A window manager is an application that is given

special permission to manipulate the entire screen.• The X protocol is a network-oriented

communication protocol by which an instance of Xlib can exchange data and events with the X kernel.

• The client which runs only the X kernel is called X terminals.

The X-Window System

The basic organization of the X Window System

User Interfaces – Compound Documents

• Modern user interfaces allow applications to share a single graphical window and use that window to exchange data through user actions.

• Compound documents are a collection of documents which are seamlessly integrated at the user-interface level.: Make the user interface application-aware to allow inter-application communication:– drag-and-drop: move objects to other positions on the

screen, possibly invoking interaction with other applications. Drag a file to drop in a trash can.

– in-place editing: integrate several applications at user-interface level (word processing + drawing facilities). Edit an image in a text document.

Client-Side Software• In many cases, a part of processing is executed on

the client side.• Essence: Client software comprises components for

achieving distribution transparency.– Access transparency is handled through client-side stubs

for RPCs and RMIs.– Location/migration transparency can be handled by

letting client-side software keep track of actual location.– Replication transparency can be achieved by forwarding

an invocation request to multiple replica.– Failure transparency can often be placed only at client

(we're trying to mask server and communication failures).– Concurrency transparency can be handled through special

intermediate servers (transaction monitors).

Client-Side Software for Distribution Transparency

A possible approach to transparent replication of a remote object using a client-side solution.

Servers• Basic model:

– A server is a process implementing a specific service on behalf of a collection of clients.

– A server is a process that waits for incoming service requests at a specific transport address.

– In practice, there is a one-to-one mapping between a port (endpoint) and a service.

– How do clients know the endpoint of a service?• Endpoints for well-known services are globally assigned

by the Internet Assigned Numbers Authority (IANA). • DCE uses a special daemon which listens to a known port

and keeps track of the current endpoint of each service. A client contact the daemon, request the endpoint, and then contact the specific server.

Servers - General Organization

• Iterative vs. concurrent servers: Iterative servers itself handles the request itself and can handle only one client at a time. A concurrent server does not handle the request itself but pass it to a separate thread or another process.

• Superservers: Servers that listen to several ports, i.e., provide several independent services. In practice, when a service request comes in, they start a subprocess to handle the request (UNIX inetd)

Servers: General Design Issues

a) Client-to-server binding using a daemon as in DCEb) Client-to-server binding using a superserver as in UNIX

3.7

Out-of-Band Communication• Issue: Is it possible to interrupt a server once it has accepted

(or is in the process of accepting) a service request?• Non-Solution: Exit the client application and restart it.• Solution 1:Use a separate port for urgent data (possibly per

service request):– The Server has a separate thread (or process) waiting for incoming

urgent messages.– When the urgent message comes in, the other request is put on hold.– Note: The OS is required to support high-priority scheduling of

specific threads or processes.

• Solution 2:Use out-of-band communication facilities of the transport layer.– Example: TCP allows to send urgent messages in the same

connection.– Urgent messages can be caught using OS signaling techniques.

Servers and State • Stateless servers never keep information on the state of a client.

– Don't record whether a file has been opened (simply close it again after access).

– Don't promise to invalidate a client's cache.– Don't keep track of the clients.

• Example: Web servers.• Consequences

– Clients and servers are completely independent.– State inconsistencies due to client or server crashes are reduced.– Possible loss of performance because, e.g., a server cannot anticipate the

client behavior (think of prefetching file blocks).

• Question: Does connection-oriented communication fit into a stateless design? – Stateful connections do not violate the statelessness of servers.

Servers and State• Stateful servers keep track of the state of their clients.

– Record a file that has been opened, so that prefetching can be done.

– Know which data a client has cached, and allows clients to keep local copies of shared data.

• Observation: The performance of stateful servers can be extremely high, provided clients are allowed to keep local copies.

• Consequence: If the server crashes, a stateful server needs to recover its entire state before its crash. Enabling recovery introduces complexity.

• A stateless server can use a cookie. It is a small piece of data containing the client information which is stored on the client. – Example: Web browser.

Object Servers • An object server is a server tailored to support

distributed objects.– An object server by itself does not really provide a

specific service.– Specific services are implemented by the objects

that reside in the server.– It is easy to change services by simply adding and

removing objects.– An object server acts as a place where objects live.– An object consists of two parts: data representing

its state and code forming the implementation of its methods.

Object Servers • Invoking objects

– Use a uniform way to invoke objects such as DCE. It is inflexible and constrains developers.

– Support different policies:

• Object invocation: – Invoke a (transient) object one at a time (consuming time to

invoke objects).

– Invoke all objects at a time (consuming resource).

• Data sharing: – Objects share neither data nor code. (e.g. separate security

policies)

– share code (e.g. database object that access a database).

• Threading: A thread per object (adv.: concurrent control) or a thread per method.

Object Adapter • Decisions on how to invoke an object are

referred to as activation policies.• A mechanism to group objects per policy is

called an object adapter, or object wrapper.• An object adapter can best be thought of as

software implementing a specific activation policy.

• An object adapter has one or more objects under its control. Several object adapters (each adapter represent a different activation policy) may reside in the same server.

Object adapter

• Object adapter: The ‘manager’ of a set of objects:– Inspects (as first) incoming requests.– Ensures referenced object is activated (requires

identification of servant).– Passes request to appropriate skeleton, following

specific activation policy.– Responsible for generating object references.

• Observation: Object servers determine how their objects are constructed.

Object Servers

• Skeleton: Server-side stub for handling network I/O:– Generated from interface specifications

– Unmarshall incoming requests, and call the appropriate servant code.

– Marshall results and send the reply message.

• Servant: The actual implementation of an object, sometimes containing only method implementations:– Collection of C, Fortran, or COBOL functions, that act on

structs, records, database tables, etc.

– Java or C++ classes

Object Adapter

Organization of an object server supporting different activation policies.

Object Adapter Implementation• Consider an object adapter that manages a

number of objects. The adapter implements the policy that it has a single thread of control fro each of its objects.

• Object adapter implementation– The header file of the adapter (e.g. header.h)– The thread library (e.g. thread.h)– The implementation code of a thread-per-object

• The request demultiplexer can be replaced by an object adapter. CORBA uses this approach.

Object Adapter

The header.h file used by the adapter and any program that calls an adapter.

/* 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); /* register an object */void unrigester_object (long object)id); /* unrigester an object */void invoke_adapter (message *request); /* call the adapter */

Object Adapter

The thread.h file used by the adapter for using threads.

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. */

Object Adapter

The main part of an adapter that implements a thread-per-object policy.

Code Migration

• Reasons for migrating code– Overall system performance can be improved if

processes are moved from heavily-loaded to lightly-loaded machines.

– Code migration makes sense to process data close to where those data reside.

– Code migration exploits parallelism.– Flexibility – dynamically configuring distributed

systems.

Code Migration• Dynamically configuring distributed systems:

– The code is available to the client at the time the client application is being developed.

– The code is downloaded when required.• Advantages:

– Clients need not have all the software preinstalled.

– The client-server protocol and its implementation can be changed as requested.

• Disadvantages: It is not secure to blindly trust the downloaded code.

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• Object components [Fugetta et al., 1998]

– Code segment contains the set of instructions.– Data segment contains the data references such as

files, printers, devices, other processes, and more.– Execution segment contains current execution state

of a process, consisting of private data, the stack, and the programming counter.

• Weak mobility: Move only code and data segment and start execution from the beginning after migration:– Relatively simple, especially if code is portable– Example: Java applets.

Models for Code Migration• Strong mobility: The execution segment can be

transferred as well.– Migration: move the entire object from one machine to the

other.– Cloning: simply start a clone, and set it in the same

execution state.– Example: D’Agents

• In sender-initiated migration, the migration is initiated at the machine where the code currently resides or is being executed. Examples:– Uploading code to the sever: The clients need to be

registered and authenticated at the server.– Sending a search program across the Internet to a Web

database server to perform the queries at that server.

Models for Code Migration

• In receiver-initiated migration, the initiative for code migration is taken by the target machine. Examples:– Java applets

– Downloading code can often be done anonymously.

• The migrated code can be executed:– At the target process

• For example, Java applets are downloaded and executed in the browser’s address space.

• The advantage is no separate process is required. The drawback is the target process needs to protect against malicious code.

– In a new separate process• It has the resource-access problems.

Models for Code Migration

Alternatives for code migration.

Managing Local Resources • Problem: The resource segment cannot be simply transferred

without change. An object uses local resources that may or may not be available at the target site. Examples:– Port: The migrated code gives up the port and requests a new one at the

destination.– URL remains valid irrespective of the code migration.

• Object-to-resource binding [Fuggetta et al.]– By identifier: The object requires a specific instance of a resource (e.g. a

URL, FTP server’s Internet address).– By value: The object requires the value of a resource (e.g. standard libraries).– By type: The object requires that only a type of resource is available (e.g. a

local device such a color monitor, a printer).• Resource types

– Unattached: The resource can easily be moved along with the object (e.g. a data file).

– Fastened: The resource can, in principle, be migrated but only at high cost (e.g. local databases and Web site).

– Fixed: The resource cannot be migrated, such as local devices or communication endpoint.

Migration and Local Resources

• Actions to be taken with respect to the references to local resources when migrating code to another machine.– MV: Move the resource – GR: establish a Global system-wide Reference– CP: Copy the value of the resource– RB: Rebind process to locally available resource

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

Managing Local Resources

• Scenario of binding by identifier with unattached resource:– When a process is bound to a resource by identifier

and the resource is unattached, it is best to move it along with the migrating code.

– If the resource is shared by other processes, a global reference can be established. But the cost of the global reference might be high (Consider the situation if the resource is a video stream).

Managing Local Resources

• Scenario of binding by identifier with fixed resource:– When migrating a process that is making use of a

local communication endpoint. – Two possible solution:

• Set up a connection to the source machine after it has migrated and has a proxy process at the target machine. What happens if the source machine malfunctions?

• Change their global reference, and send messages to the new communication endpoint at the target machine.

Managing Local Resources • Scenario of binding by value:

– Unattached resource: copying the resource to the new destination is better than a global reference.

– Fasten resource: Establishing a global reference is better than copying runtime libraries.

– Fixed resource: A process assumes that memory can be shared between processes. Establishing a global reference needs to implement distributed shared memory.

• Scenario of binding by type:– The obvious solution is to rebind the process to a

locally available resource of the same type.

Migration in Heterogeneous Systems• Main problem:

– The target machine may not be suitable to execute the migrated code.

– The definition of processor/process/thread context is highly dependent on local hardware, operating system, and runtime system (e.g. platform-specific data).

• For weak mobility it suffices to recompile the source. For strong mobility the execution segment is also migrated. The recompilation is not enough.

Migration in Heterogeneous Systems• Solution (migration stack):

– The migration stack is the copy of the program stack maintained on the runtime system.

– Existing languages allow migration at specific ‘transferable’ points, such as just before a function call.

• Solution (virtual machine): Make use of an abstract machine that is implemented on different platforms.– Interpreted languages running on a virtual machine

(Java/JVM; scripting languages)

Migration in Heterogeneous Systems

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

3-15

Example: D'Agents

• D’Agents formerly called Agent Tcl (Tool Command Language), is a system that is built around the concept of an agent. Refer to http://agent.cs.dartmouth.edu/

• An agent in D’Agents is a program that can migrate between different machines. Programs can be written in an interpretable language such as Tcl, Java, or Scheme.

D'Agents

• D'Agents provides support for– Sender-initiated weak mobility (agent_submit

command)– Strong mobility by process migration

(agent_jump command)– Strong mobility by process cloning (agent_fork

command)

Overview of Code Migration in D'Agents

• A simple example (send-initiated weak mobility) of a Tcl agent in D'Agents submitting a script to a remote machine (adapted from [gray.r95])

• agent_receive is blocked until the result is received.

proc factorial n { if ($n 1) { return 1; } # fac(1) = 1 expr $n * [ factorial [expr $n – 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

• An example (send-initiated strong mobility) of a Tcl agent in D'Agents migrating to different machines where it executes the UNIX who command (adapted from [gray.r95])

• agent_jump allows the process to move to other machine.

all_users $machines

proc all_users machines { set list "" # Create an initially empty list foreach m $machines { # Consider all hosts in the set of given machines agent_jump $m # Jump to each host set users [exec who] # Execute the who command append list $users # Append the results to the list } return $list # Return the complete list when done}

set machines … # Initialize the set of machines to jump toset this_machine # 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)

D'Agents• Organization: Each machine is built as a five-layered

system:– TCP/IP and E-mail layer implements a common interface to

the communication facilities of the underlying network.– Server layer is responsible for agent management,

authentication, and communication management between agents.

– Agent Run Time System (Core) layer consists of a language-independent core that supports the basic model of agents such as starting and ending an agent.

– Language interpreter layer consists of the language interpreter, a security module, an interface to the core layer, a module to capture the state of a running agent.

– Agent layer: Each agent is executed by a separate process.

Implementation Issues

The architecture of the D'Agents system.

D'Agents• The more difficult part in the implementation of

D’Agents, is capturing the state of a running agent and shipping that state to another machine.

• There are four tables containing global definitions of variables and scripts, and two stacks for keeping track of the execution status.

• When an agent calls agent_jump, by which the agent migrates to another machine.– The complete state of the agent as just described is marshaled

into a series of bytes.– The D’Agents server on the target machine subsequently

creates a new process to handle the marshaled data, which is then unmarshals into the state when the agent called agent_jump.

Implementation Issues

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 framesStack of activation records, one for each running command

What is a Software Agent?

• Definition: An autonomous process capable of reacting to and initiating changes in its environment, and of performing a task in collaboration with users and other (remote) agents.

• The feature that makes an agent more than just a process is its capability to – act on its own and take initiative where

appropriate– cooperate with other agents

Taxonomy of Agents• It seems hard for researchers to reach agreement on a

single taxonomy:– collaborative agent: collaborate with others in a multiagent

system.• A multiagent system is a system in which agents seek to achieve

some common goal through collaboration.• Example: Agents collaborate in setting up a meeting

– mobile agent: can move between machines• Example: Agents which retrieve information distributed on the

Internet– interface agent: assist users in the use of one or more

applications (usually with learning ability). • Example: agents which seek to bring buyers an sellers together.

– information agent: manage information from physically different sources

• Example: e-mail agent, mobile information agent.

Software Agents in Distributed Systems

Some important properties by which different types of agents can be distinguished.

PropertyCommon 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 YesCan 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

Agent Technology• The Foundation for Intelligent Physical Agent (FIPA)

is developing a general model for software agents [FIPA, 1998b] (http://www.fipa.org/)

• In this model, agents are registered at, and operate under the management of an agent platform:– Management: Keeps track of where the agents on this

platform are.• creating and deleting agents.• mapping globally unique agent ID to a local communication

endpoint (port)– Directory: Mapping of agent names and attributes to agent

IDs– ACC: Agent Communication Channel, used to

communicate with other platforms • Communication between ACCs on different platforms follows

Internet Inter-ORB Protocol (IIOP).• Example: server in D'Agents

Agent Technology

The general model of an agent platform (adapted from [fipa98-mgt]).

Agent Language

• Communication between agents takes place by means of an application-level communication protocol, which is referred to as an agent communication language (ACL).

• ACL makes distinction between purpose and content of a message.

Agent Language

• An ACL message can have a limited number of purposes.

• A message consists of:– a header

• Identifier of the purpose of message,

• Fields for identifying the sender and receiver,

• A field to identify the language or encoding scheme,

• A field to identify a standardized mapping of symbols to their meaning. Such a mapping is called ontology.

– the actual content.

Agent Communication Languages

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 sourceReference to source

Agent Communication Languages

A simple example of a FIPA ACL message sent between two agents using Prolog to express genealogy information.

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)