Processes

Chapter 3

Processes

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

• In distributed systems threads allow clients can 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: we build virtual processors in software, on top of physical processors:– Processor: Provides a set of instructions along with the

capability of automatically executing a series of those instructions.

– Thread: A minimal software processor in whose context a series of instructions can be executed. Saving a thread context implies stopping the current execution and saving all the data needed to continue the execution at a later stage.

– Process: 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.

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).

• 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).

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

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: light-weight processes that can execute user-level threads.

• 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, an 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: Main issue is hiding

network latency• Multithreaded Web client:

– 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• 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 issue is improved performance and better 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– As with clients: hide network latency by reacting to next

request while previous one is being replied• Better 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):– Server has a separate thread (or process) waiting for incoming urgent

messages– When urgent message comes in, associated request is put on hold– Note: we require OS supports 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 accurate information about the

status of a client after having handled a request:– 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 your 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

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 keeps track of the status of its clients:

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

– Knows 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. As it turns out, reliability is not a major problem.

• 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 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.

• Invoke a (transient) object one at a time or all objects at a time.

• Objects share no data and code or share code.

• A thread per object or a thread per method.

• Decisions on how to invoke an object are referred to as activation policies.

Object Servers

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

records, database tables, etc.– Java or C++ classes

• Skeleton: Server-side stub for handling network I/O:– Unmarshalls incoming requests, and calls the appropriate

servant code– Marshalls results and sends reply message– Generated from interface specifications

Object Adapter

• 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 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– The thread library– 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: Move component, including

execution state– 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.– Uploading code to the sever: The clients need to be

registered and authenticated at the server.

Models for Code Migration

• In receiver-initiated migration, the initiative for code migration is taken by the target machine. For example, 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

Models for Code Migration

Alternatives for code migration.

Managing Local Resources • Problem: An object uses local resources that may or may not

be available at the target site. For example, port vs. URL.• Object-to-resource binding

– 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.– GR: establish a Global system-wide Reference– MV: Move the resource– 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:

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

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

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

• 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 process/thread/processor context is highly dependent on local hardware, operating system and runtime system (e.g. platform-specific data)

• Only solution: Make use of an abstract machine that is implemented on different platforms

• Current solutions:– 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.– 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 Tel 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 Tel 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 in 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's an 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].

• 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 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 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

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)