chapter 3 processes 1 processes chapter 3 chapter 3 processes 2 introduction a process is a...
Post on 22-Dec-2015
224 views
TRANSCRIPT
Chapter 3 Processes 1
Processes
Chapter 3
Chapter 3 Processes 2
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
Chapter 3 Processes 3
Topics Covered Threads Clients Servers Code Migration Software Agents
Chapter 3 Processes 4
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
Chapter 3 Processes 5
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
Chapter 3 Processes 6
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?
Chapter 3 Processes 7
Interprocess Communication
If separate processes, 3 context switches
If same process, but separate threads, more efficient
Chapter 3 Processes 8
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
Chapter 3 Processes 9
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
Chapter 3 Processes 10
Threads and LWPs
A bunch of LWPs hang around LWPs grab threads as needed
Chapter 3 Processes 11
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.)
Chapter 3 Processes 12
Multithreaded Servers
Multithreaded server o dispatcher/worker model
Chapter 3 Processes 13
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
Chapter 3 Processes 14
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
Chapter 3 Processes 15
Clients Client interacts with user and
server UI is sometimes simple
o Cell phone Sometimes UI is not-so-simple
o X Window System
Chapter 3 Processes 16
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
Chapter 3 Processes 17
X Window System
Organization of X Window System
Chapter 3 Processes 18
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
Chapter 3 Processes 19
Access transparencyo Client stub (middleware)
Location, migration, and relocation transparencyo Naming
Replication transparencyo One approach is on next slide
Client-Side Transparency
Chapter 3 Processes 20
Client-Side Transparency
Replication transparencyo Client (stub) invokes object on all replicaso Collects responses and passes one result to
client
Chapter 3 Processes 21
Failure transparencyo Client middleware repeatedly attempt
to connect to servero Client middleware tries another servero Client provides cached result
Concurrency/persistence transparencyo ?????
Client-Side Transparency
Chapter 3 Processes 22
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)
Chapter 3 Processes 23
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”
Chapter 3 Processes 24
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
Chapter 3 Processes 25
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
Chapter 3 Processes 26
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?
Chapter 3 Processes 27
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
Chapter 3 Processes 28
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
Chapter 3 Processes 29
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)?
Chapter 3 Processes 30
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?
Chapter 3 Processes 31
Reason for Migrating Code
Dynamically configuring cliento Client fetches necessary softwareo Then client contacts server
Chapter 3 Processes 32
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
Chapter 3 Processes 33
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
Chapter 3 Processes 34
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?
Chapter 3 Processes 35
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?)
Chapter 3 Processes 36
Models for Code Migration
Alternatives for code migration
Chapter 3 Processes 37
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
Chapter 3 Processes 38
Migration and Local Resources
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.)
Chapter 3 Processes 39
Migration and Local Resources
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
Chapter 3 Processes 40
Migration and Local Resources
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
Chapter 3 Processes 41
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
Chapter 3 Processes 42
Migration in Heterogeneous Systems
Maintaining a migration stack to support migration of an execution segment
Can be done in C/C++
Chapter 3 Processes 43
Migration in Heterogeneous Systems
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
Chapter 3 Processes 44
Code Migration in D'Agents
Middleware approach Supports various forms of code
migration Read it!
Chapter 3 Processes 45
Software Agents So far
o Threadso Clientso Serverso Mobility
And now for something completely different…
Software agents
Chapter 3 Processes 46
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
Chapter 3 Processes 47
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
Chapter 3 Processes 48
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?
Chapter 3 Processes 49
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
Chapter 3 Processes 50
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
Chapter 3 Processes 51
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
Chapter 3 Processes 52
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
Chapter 3 Processes 53
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
Chapter 3 Processes 54
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)
Chapter 3 Processes 55
Summary Threads
o Sequential programmingo Parallel processing
Clientso User interfaceo Distribution transparency
Chapter 3 Processes 56
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
Chapter 3 Processes 57
Summary Software agents
o Autonomous and cooperativeo Agent communication language (ACL)o Purpose vs content