Chapter 3 Processes 1 Processes Chapter 3 Chapter 3 Processes 2 Introduction A process is a...

Chapter 3 Processes 1

Processes

Chapter 3


Introduction A process is a program in

execution For OS important issues are

o Management of processeso Scheduling of processes

In dist systems, issues such aso Multithreadingo Process/code migrationo Software agents


Topics Covered Threads Clients Servers Code Migration Software Agents


Threads Processes (not threads): OSs makes

sureo Processes do not affect each other,

accidentally or intentionally (separation)o Processes not aware of each other

(concurrency transparency) Costly to set up independent processes Switching between processes is costly

o Must save state of current processo Must restore state of new processo Might also have to swap to disk


Threads Thread is like a (sub)process But, OS does not provide concurrency

transparency between threads For example, don’t protect data from

access by other threads within a process

Plusses?o Efficiency

Minuses?o More work for application developer


Threading Example Spreadsheet program

o Change to one cell updates many cellso Interface is one thread, update anothero Gives impression both are simultaneouso Even better in multiprocessor system

Other examples?o Word processor

Distributed examples?


Interprocess Communication

If separate processes, 3 context switches

If same process, but separate threads, more efficient


Thread Implementation Two possible approaches

o User-level threads all in user spaceo Kernel-level threads kernel is involved

User-level threadso Plus: cheap to create/destroy threadso Plus: thread context switch is cheapo Minus: Blocking system call will block all

threads in process (e.g., blocking on I/O) Kernel-level threads remove the

“minus”o But thread context switching is more costly


Lightweight Processes User-level threads and… Lightweight processes (LWPs) that

act like kernel-level threads LWPs take care of threads as needed Plusses?

o Thread stuff is efficient (user-level)o Blocking system call will not suspend all

threads (provided enough LWPs)o Apps need not be aware of LWPso LWPs can execute on different processors


Threads and LWPs

A bunch of LWPs hang around LWPs grab threads as needed


Threads in Dist Systems Advantage to threads in dist system

o Can block without stalling entire process Multithreaded clients

o Conceal communication delays o For example, a Web browser

Multithreaded serverso More benefit on server side than cliento Process incoming requests and do local

thingso Without threading, could implement this as

a “big finite-state machine” (saving state, etc.)


Multithreaded Servers

Multithreaded server o dispatcher/worker model


Multithreaded Servers

Three ways to construct a servero Single thread process stallso Finite state machine hard to programo Threads totally awesome, dude

Threads rule!

Model Characteristics

Threads Parallelism, blocking system calls

Single-threaded process No parallelism, blocking system calls

Finite-state machine Parallelism, nonblocking system calls


Threads: The Bottom Line Consider RPC with blocking system call

o Easy to program, but…o Inefficient without threads since…o No parallelism

W/O threads, finite state machineo Then obtain parallelismo But very painful to program

Threads provideo Sequential programming and parallel

processes


Clients Client interacts with user and

server UI is sometimes simple

o Cell phone Sometimes UI is not-so-simple

o X Window System


X Window System X Window System consists of

o X kernel low level interface for screen, mouse, etc.

o Xlib to access X kernelo Window manager app that can

manipulate screeno X protocol allows for X kernel and X

app to reside on different machineso X terminals client using X protocol


X Window System

Organization of X Window System


Consider ATM and TV set-top boxo For these, UI is small part of client

sideo Lots of processing on client side, lots

of communication from client side Client-side transparency is possible Server side transparency harder to

achieve (performance issues)o And not so important

Client-Side Transparency


Access transparencyo Client stub (middleware)

Location, migration, and relocation transparencyo Naming

Replication transparencyo One approach is on next slide




Replication transparencyo Client (stub) invokes object on all replicaso Collects responses and passes one result to

client


Failure transparencyo Client middleware repeatedly attempt

to connect to servero Client middleware tries another servero Client provides cached result

Concurrency/persistence transparencyo ?????



Servers Server a process implementing a

service for a collection of clientso Server waits for incoming requestso Server services requests

Server can be iterative or concurrento Iterative handles request, responseo Concurrent passes request to

another process/thread (fork a new process)


Servers Requests arrive at an endpoint

o Port How does client know endpoint?

o Well-knowno Some service to look it up

Superserver serves serverso Listens for a bunch of “servers”


Client-to-Server Binding

a) Client-to-server binding using a daemon as in DCE

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


Other Server Issues How to interrupt server?

o Break connection (common in Internet)o Out of band data

Stateless vs stateful Stateless no memory of clients and

can change its state without telling clientso For example, a Web server (w/o cookies)

Stateful remembers its clientso For example, file server must remember

who has file at any given time


Stateless vs Stateful Stateless vs stateful server What if server crashes… Stateless?

o No problem, just restart Stateful?

o Big problems… Security of stateless vs stateful?


Object Server Server designed for dist objects

o “a place where objects live”o Easy to change services on server

Read Section 3.3.2


Code Migration Code migration passing programs

o Perhaps even while executing Expensive, so why bother? Consider process migration

o Move a process to another machineo Move process from heavily loaded machineo A form of load balancing

When is it worthwhile?o Not easy to calculate in heterogeneous

networko Minimizing communication may be good

reason


Code Migration For example

o Server manages a huge databaseo Spse client needs to access and

process lots of datao May save bandwidth by shipping

process to the server Other examples (wrt

performance)?


Code Migration Code migration might also

increase flexibility For example, it might be possible

to dynamically configure the system

Dynamically download client softwareo No need to pre-install softwareo Other benefits?o What about security?


Reason for Migrating Code

Dynamically configuring cliento Client fetches necessary softwareo Then client contacts server


Models for Code Migration Process consists of 3 segments

o Code segment self explanatoryo Resource segment external resourceso Execution segment current state

Weak mobility migration of code segment and some initialization datao For example, Java appletso Simple, only requires code is portableo Execute in current process, or start new one


Models for Code Migration Strong mobility migrate exe

segmento Running process stopped, moved to another

machine, starts where left offo For example, D’Agentso Complex but powerful

Instead of moving the process, might clone the processo Then runs in parallel at client and server

Why?o Cloning improves transparency


Models for Code Migration Sender or receiver initiated? Sender initiated

o Initiated by machine where code resideso For example, uploading program to servero Other examples?

Receiver initiatedo Initiated by target machineo For example, Java appletso Other examples?


Models for Code Migration Receiver initiated client takes initiative

o Code migrates to cliento Done for performance reasons

Sender initiated server takes initiativeo Code migrates to servero Probably want access to server data

Receiver initiated iso Simpler (why?)o More secure (why?)


Models for Code Migration

Alternatives for code migration


Migration and Local Resources

What about resource segment? Spse process is using a specific

port for communicationo This info is in resource segment

If process migrates, gets a new port

But an absolute URL will not changeo Also in resource segment



3 types of process-to-resource binding Binding by identifier

o Known locally and remotely o For example, URL or IP address

Binding by valueo Available locally and remotely, but location

might be different o C or Java library

Binding by typeo Only available locallyo Local devices (printers, monitors, etc.)



3 types of resource-to-machine bindings Unattached resources

o Easy to move from one machine to anothero Such as data files used by programs

Attached resourceso Difficult to move from on machine to

anothero Such as database or entire website

Fixed resourceso Cannot be movedo Such as local devices



GR establish global systemwide reference MV move the resource CP copy the file to the resource RB rebind process to locally available

resource

GR

GR

RB (or GR)

GR (or MV)

GR (or CP)

RB (or GR, CP)

MV (or GR)

CP ( or MV, GR)

RB (or GR, CP)

By identifier

By value

By type

FixedAttachedUnattached

Resource-to machine binding

Process-to-resource

binding


Migration in Heterogeneous Systems

Code executes on different platforms Each platform must be supported Easier if limited to weak mobility

o Different code segments In strong mobility, difficult… Restrict migration to certain points in

codeo Such as a function call

Maintain machine independent stacko Migration stack



Maintaining a migration stack to support migration of an execution segment

Can be done in C/C++



Migration in heterogeneous systems o Basic problem is similar to portability

What is the solution for portability? o Virtual machine is one solution

So similar solution should work here


Code Migration in D'Agents

Middleware approach Supports various forms of code

migration Read it!


Software Agents So far

o Threadso Clientso Serverso Mobility

And now for something completely different…

Software agents


Software Agents Software agents no precise definition

o “Autonomous agents capable of performing a task in collaboration with other, possibly remote, agents”

o “An autonomous process capable of reacting to, and initiating change in, its environment, possibly in collaboration with users and other agents”

Able to act on its own (autonomous) Able to cooperate with other agents Able to take the initiative


Software Agents Collaborative agents

o Agents that work together as part of multiagent system

o Example: agents that arrange a meeting

Mobile agentso Able to move between machineso May require strong mobilityo Example: to “police” the Internet


Software Agents Interface agents

o Assist users with one or more applicationso Actively learns from its interactionso Example: agent that brings buyers and

sellers together Information agents

o Manage info from many different sourceso In distributed system, info is from physically

distributed systemso Example: email agent to filter spam, others?


Software Agents

Properties of software agents

Capable of learningNoAdaptive

Can migrate from one site to anotherNoMobile

Has a relatively long lifespanNoContinuous

Can exchange information with users and other agents

YesCommunicative

Initiates actions that affects its environmentYesProactive

Responds timely to changes in its environmentYesReactive

Can act on its ownYesAutonomous

DescriptionCommon to all agents?

Property


Intelligent Agents Foundation for Intelligent Agents

o FIPA Developing general model for

agents Agents registered at agent

platform Platform provides basic services

o Create and delete agentso Locate agents (directory service)o Inter-agent communication facilities


FIPA Platform

FIPA model for an agent platform Agent Communication Channel (ACC)

o Sending messages between platformso Uses Internet Inter-ORB Protocol (IIOP) Chapter 9


ACL FIPA defines Agent Communication

Languageo Defines a “high level communication protocol

between a collection of agents”o How does this differ from IIOP?

Separation between msg purpose and contento Header states the msg purposeo Format and language of content is left openo Need enough info in header to interpret contento Ontology: mapping of symbols to meanings


ACL

Different “purposes” in FIPA ACL

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 performedAction specification

SUBSCRIBE Subscribe to an information sourceReference to source


ACL Example

Sender INFORMs receiver of Dutch royal genealogy Ontology says that Prolog statements to be

semantically interpreted as genealogy info

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)

http://www.nsa.gov/docs/venona/

http://www.nsa.gov/docs/venona/


Summary Threads

o Sequential programmingo Parallel processing

Clientso User interfaceo Distribution transparency


Summary Servers

o Efficiency more important than transparency

o Interactive or concurrent?o Stateful or stateless?o Object servers

Code migrationo Performance and flexibilityo Strong mobility vs weak mobilityo Local resources?o Heterogeneity/virtual machines


Summary Software agents

o Autonomous and cooperativeo Agent communication language (ACL)o Purpose vs content

Chapter 3 Processes 1 Processes Chapter 3 Chapter 3 Processes 2 Introduction A process is a...

Documents

Transcript of Chapter 3 Processes 1 Processes Chapter 3 Chapter 3 Processes 2 Introduction A process is a...