1

Processes and Distributed Computing

Issues:

• moving processes around

• design of server and client processes

• migration of processes/programs

• agent programs

Processes without Threads are almost useless in

distributed processing

2

Process Communication

Context switching as the result of IPC

Usual Mechanisms are:•Pipes•Message Queues•Shared SegmentsWhat do they all have in common??

3

Threads as a Core Mechanism

A thread can be seen as a program in execution on a virtual processor

Thread context: CPU status + some more information on (needed for thread management).

For instance a thread may be currently blocked

on a mutex variable and this information can be used so

that it does not get scheduled for execution.

4

Why Threads are Useful in Distributed Systems??

If a system is implemented as a single-threaded process that blocks on a system call, the whole process gets delayed..

If a multiprocessor system is available, threads can be executed with different processors (real parallelism).

How are threads implemented?

5

Options for ImplementationThreads are provided in the form of a thread package.

Advantages (of a library implemented entirely in user-space):

• Cheap to create/destroy threads• Switching among threads is inexpensive (a few instructions

only- no need to change memory maps, deal with CPU, flushing the TLB etc.

Disadvantages (of the user-space library):• Invocation of a blocking system call will block the entire

process.. (bad as no other thread can proceed..)

6

Other Options• Kernel-threads…

but this has disadvantages as it essentially suffers from the many possible thread-switch operations (which have the same cost as process context switches).

• Approach in between: Lightweight Processes (LWP)

7

Light Weight Processes

• A LWP runs in the context of a process• Multiple LWPs may exists per process• A user-thread package available for applications (to

create/destroy threads) – implemented entirely on the user-space.

• The package provides sync primitives (mutexes/condition variables)

• Every LWP can run its own user-thread.• Assigning a thread to a LWP is implicit (hidden from the

programmer).

8

LWPs & User Threads• LWP are created by system calls and is given its own stack.• When an LWP is created runs the sched to find a thread to run• If there are more than one LWP, then all of them run the sched.

• The thread table is kept in user-space (protection is done by mutexes)-sync does NOT need kernel-support.

• When a LWP find a runnable thread context switches to it.• If a thread needs to block on a mutex or cond variable, it does its own

administration and then calls the sched. When another runnable thread is found, a context switch is made to that thread..

• End Result: the LWP need not be informed about the last context switch (which happens entirely in user-space).

9

Blocking Threads

When a thread makes a blocking system call:

• Change from user-space to kernel

• If the current LWP can continue (with another thread it does so)

• Otherwise, the OS may decide to run LWP

• Ultimately another context switch needs to be made back to kernel.

Similar approach: Scheduler Activations [Anderson 1991]

• When a thread block (on a blocking system call) the kernel does a upcall to the thread package and calls the scheduler routine to pick one thread for execution.

10

Thread Implementation

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

11

Threads in Distributed Systems

• Convenient mechanism to allow blocking calls without blocking entire processes/systems

• Mechanism to hide network latencies and delays.

Example: a browser (client) program and the way it retrieves and displays information.

- multiple operations may happen concurrently.

12

Multithreaded Servers

A multithreaded server organized in a dispatcher/worker model.

Threads are extremely useful when one writes server code

13

Multithreaded ServersThree 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

•In Finite-state machine model, the only process in the server services requests but also marks the state of each process.•Finite-State machine model: complicated to program

14

Client Organization:X-Window System Example

The basic organization of the X Window System

•It does provide functionality transparency for the Interface

15

Client-Side Organization for Data Distribution Transparency

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

Failure transparency(at the client site)?? If a client cannot connect to a server

after a number of attempts, it does try another one..

16

Design Issues for Servers• Iterative server

– The server itself handles the request and if possible returns a result

• Concurrent server– The server passes the request to a different server (thread)– After that it waits for the next incoming request…

• Endpoints/Ports:– How do clients know about them??– Some are standard ie, ftp is at 21, http at 80 etc.– Some services do not require pre-assigned endpoint.

• One solution is DCE style• Another use a superserver (ala Unix) – forks a new process to

handle incoming requests (via the inetd)

17

Servers Design Issues

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

18

Server Design Issues

• How to interrupt a server?– Exit the application

– Send out-of-band data (separate data and control streams)

• Stateless servers– Does not keep any information about the state of clients

• Stateful servers– A file server that allows a client to keep a local copy of a file and the client

does updates on the file.

– Plus: can improve performance (as far as the client is concerned)

– Minus: in light of a crash the server have to re-acquire the “state-of-affairs” just before the crash…

• Cookies– Why are they used? What is good/bad about them?

19

Object Servers• Developed to support distributed objects• An object server does not provide a specific service• Services are implemented by various objects resident in

the server (or various servers).

• Object– Data representing its state

– Code (with the implementation of the methods).

• Issue: how does a server invoke its objects?– In a multi-threaded server, each object may be assigned a

thread.

– Alternatively, a thread can be used for each invocation request.

20

(Activation) Policies for Invoking Objects

• Policy I: An object is generated the first time it is invoked and if it is transient it has to go when no client binds to it..

• Policy II: An object is always alive waiting to be contacted.

• Policy III: An object is generated for the first time it is invoked and remains alive until Greece becomes a rational place.

21

Object Adapter

Organization of an object server supporting different activation policies.

•Decisions on how to invoke an object are known as activation policies•Mechanism that groups objects together per activation policy is called object adaptor/object wrapper.•Adaptors are unaware of the specific interfaces of the objects they control.

22

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

23

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

24

Object Adapter

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

25

Why Migrating of 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.

Needed often for better Load Sharing and Balancing•Move work from lightly to heavily loaded nodes.

26

Types of MobilityProcesses consist of [Fugetta 98]• Code segment (set of instructions that make up the

program)• Resource segment (references to external resources)• Execution segment(stores the current execution state)

• Weak mobility: transfer only the code section (Java applets).

• Strong mobility:transfer the execution section as well (D’Agents).

27

Models-Alternatives for Code Migration

28

Migration and Local Resources

Transferring a resource is sometimes exceedingly difficult (if not impossible)

• Move a process that holds a specific TCP port..• Move a process that accesses a file via a URL.

[Fugetta 98] classifies process-to- resource bindings

1. By identifier (the strongest)

2. By value (weaker – C library that may be local but in a different location in the target FS).

3. By type (process indicates that it needs –references- specific type of resources such as printers, monitors, etc

29

Local ResourcesIf and how a reference should be changed depends on whether

that resource can be moved along to the target machine.

Resource-to-machine bindings• Unattached resources (ie, data files – can be easily moved

around)• Fastened Resources(may be moved but expensive – ie,

databases, web sites etc)• Fixed Resources (specific site resources such as local

communication endpoints).

30

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 referenceMV: move the resourceCP: copy the value of the resourceRB: rebind process to locally available resource

31

Migration in Heterogeneous Systems

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

3-15

Weak mobility possible only when a program migrates between Procedure calls (use idea of migration stack-machine independent)

32

Agents..

Agent is an autonomous process that can react to, and/or initiate changes in its environment (possibly with the collaboration of other processes and/or users).

33

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

34

Agent Technology

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

35

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

36

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)