Transcript Processes - Ubiquitous Computing Lab

Processes
Muhammad Rafi
Real-Time & MultiMedia Lab
Presentation Outline
•
•
•
•
•
•
•
•
Process - an operating system view
Thread - an operating system view
Thread – in a distributed system
Client/Server Architectures
Clients
Server
Code Migration
Software Agents
Real-Time & MultiMedia Lab
Process- an operating system view
• Process = a program in execution
• A process needs certain resources, including CPU time,
memory, files, and I/O devices, to accomplish its task.
• Initially there was only one process per processor. So
through-put was very low as compared to the cost of
processor.
• Processes usually have large I/O cycles as compared to
CPU cycles
• Idea was to get the maximum utilization of CPU. When a
process is in I/O cycle its must free the CPU for other
processes
Real-Time & MultiMedia Lab
Process- an operating system view
• Operating systems create Extended Machine(virtual processors) to
execute number of processes, each process is in one virtual
processor.
• OS ensure with hardware support that Processes are independent
of each other.
• OS keep track of all the processes through Process Table
• OS increase CPU utilization by
overlapping processes in I/O and
Computation cycles.
• It required a lot of over head:




Process creation
Context switching
Swapping
Co-ordination between kernal & processes
Real-Time & MultiMedia Lab
Thread - an operating system view
• To reduce the overhead of process switching between CPU bound
and I/O bound processes, Threads were introduced
• Threads are within a single process space(address space), they are
not protected with each other.
• Developers have to make sure about thread boundary and process
space.
• Context switching is cheaper, there is no kernal intervention
• While a thread executes a system call, all other peer threads may
continue their execution. (Performance)
• There are two views of threads User-Level Vs. Kernel Level
Real-Time & MultiMedia Lab
Thread Elaboration
• A set of threads share the same address space
User Level
Kernel Level
• Thread Library executed in
user mode
•Kernal Control schedule of thread
•Cheap to manage Thread
•Expensive to manage Threads and
Context switch
•Easy Context switching
•Kernel Intervention
Real-Time & MultiMedia Lab
Light-Weight Processes(LWPs)
• Support for hybrid approach (userlever and kernel level threads)
• A process contains several LWPs
• Developer: create multi-threaded
application by using library
• System: maps threads to LWPs for
Execution
•Thread creation done in the user space
•Bulk of scheduling and
synchronization of threads done in the
user space
Real-Time & MultiMedia Lab
Implementation of LWPs
• Each LWP offers a virtual CPU
• LWPs are created by system calls
• They all run the scheduler, to
schedule a thread
• Thread table is kept in user space
• Thread table is shard by all LWPs
• LWPs switch context between
threads
• When a thread blocks, LWP
schedules another ready thread
• Thread context switch is completely
done in user-address space
• When a thread blocks on a system
call,execution mode changes from
user to kernel but continues in the
context of the current LWP
• When current LWP can no longer
execute, context is switched to
another LWP
Real-Time & MultiMedia Lab
Thread In Distributed Systems
• A Distributed system is a collection of independent computers
that appears to its users as a single coherent system. The concept
of thread can be very efficiently utilize to provide this illusion.
• Important property of thread: a blocking system call will not block
the entire process
• Very attractive to maintain multiple logical connections between
many clients and a server
Real-Time & MultiMedia Lab
Threads:Process
Description
1:1
Each thread of execution is a
unique process with its own
address space and resources.
M:1
A process defines an address
space and dynamic resource
ownership. Multiple threads
may be created and executed
within that process.
Threads:Process
1:M
M:M
Description
Example Systems
Traditional UNIX implementations
Windows NT, Solaris, OS/2,
OS/390, MACH
Example Systems
A thread may migrate from one
process environment to
another. This allows a thread
to be easily moved among
distinct systems.
Ra (Clouds), Emerald
Combines attributes of M:1
and 1:M cases
TRIX
Real-Time & MultiMedia Lab
Process & Thread In Windows 2000
Real-Time & MultiMedia Lab
Process Life Cycle in Windows 2000
Real-Time & MultiMedia Lab
Client/ Server Architecture
• The data processing interaction in which a program at one site (the
client) sends a request to a program at another site (the server) and
awaits a response.
• It is a common form of distributed system in which software is
split between server tasks and client tasks. A client sends requests
to a server, according to some protocol, asking for information or
action, and the server responds.
• There are many architectural option in Client/Server
–
–
–
–
1:1
1:M
M:1
M:M
Real-Time & MultiMedia Lab
Multithreaded Client
•
•
•
•
•
•
High propagation delay in big networks
WAN: a round trip delay ~ seconds
To hide this delay, use threads
Initiate communication by a separate thread
Example: Web Browsers, Download Accelerator
Separate connection for each page component (HTML file, image,
audio…)
• Better: if server is horizontally distributed, data will be transferred
in parallel
• Very much dependent on the architecture of the server
Real-Time & MultiMedia Lab
Multithreaded Servers
• Much more Important than multi-threaded clients
• Not only simplifies server code, but also boosts server
performance (exploit parallelism)
• It is common to have multiple-CPU (Multiprocessor) server
machines
Model
Characteristics
Threads
Parallelism, blocking
system calls
Single-threaded
process
No parallelism, blocking
system calls
Finite-state machine
Parallelism, nonblocking
system calls
Real-Time & MultiMedia Lab
Client
Clients are use to interact with human user and remote server
-User Interface (UI):
-Client-side software: UI + components for achieving transparent
Client S/W includes:
+Local processing
+Communication facilities: distribution transparency
+Replication transparency
+Access transparency: client stub
+Location, migration, relocation transparency: naming
+Failure transparency
Real-Time & MultiMedia Lab
X-Window System
Goal
Generally is used to control bit-mapped terminals (include a monitor, keyboard,
mouse) (or a part of OS that controls the terminal)
X-kernel:
-Contains all terminal-specific devices
-Offer relative low-level interface for controlling the screen
-Capturing evens from the keyboard and mouse
Comprise 4 major components:
-X Servers: Managing the screen, mouse and keyboard -> interact with the
user
-X Clients: The application (where the real work gets done )
-X Protocol: Client/server communication
-X Library: The Programming interface
Real-Time & MultiMedia Lab
X-Window System
Real-Time & MultiMedia Lab
Servers: General Design Issues
Organize of server?
Iterative server (sequential server): itself handle the request and return a response to
the request.
Concurrent server: does not handle the request but passes it into threads (Ex
multithreads server)
How client contacts with server?
Way: Clients send the request to the endpoint (port) of the server
Approach 1: Endpoint is assigned with the well-know service
(Ex: FPT request listen to port 21, HTTP: port 80)
Approach 2: Not preassigned endpoint (next slice)
Solution 1: Each server has a special daemon to keep tracks of the current
endpoint of each service (Ex: DCE)
Solution 2:Using a single SuperServer (inetd in UNIX)
Real-Time & MultiMedia Lab
Servers: General Design Issues
Whether and how a server can be interrupt?
Approach 1:
Client suddenly exits the application and restarts it immediately
server thinks the client had crashed and will tear down the connection.
Approach 2 (better):
Send out-of-band data (which is process by the server before any other client data)
-Solution 1: Out-of-band data is listened by separated endpoint.
-Solution 2: Out-of-band data is sent across the same connection with urgent
State-full or Stateless server
Stateless server:
-Does not keep information on the state of its clients.
-Can change it own state without having to inform any client.
Ex: Web server
State full server:
-Does maintain information on its clients.
Ex: File server
Real-Time & MultiMedia Lab
Object Server
• Tailored for distributed objects support
• -Provides environment for objects
• -Not a service by itself (government)
• -Services are provided by objects
• -Easy to add services (by adding Objects)
Object server
Object
Object
Object
Object
Data
Code (methods)
Real-Time & MultiMedia Lab
Invoking Object
Activation Policies
• Decisions on how to invoke objects
• All objects are alike
– Inflexible
• Objects differ and require different policies
– Object type
– Memory allocation
– Threading
Transient Object
• Create at the first invocation request and destroy when clients are no longer
bound to it
• Create all transient objects when server is initialised
• Server resources?
• Invocation time?
Memory Allocation
Real-Time & MultiMedia Lab
Object Adapters
•
•
•
•
•
A S/W implementation of an activation policy
Generic to support developers
Group objects per policy
Several objects under an adapter
Several adapters under a server
Real-Time & MultiMedia Lab
Code Migration
•
•
Code Migration = moving processes between machines
Process = 3 segments
1. Text segment (the code)
2. Resource segment (refs to external resources {files, printers, devices, other
processes, etc})
3. Execution segment (state of a process {stack, program counter, registers, private
data…})
•
Why migrate code?
•
•
•
•
•
•
Performance
Load balancing
Exploiting parallel environment
Minimization communication and computation cycles
Flexibility
Security may be a threat?
Real-Time & MultiMedia Lab
Scenario of 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.
Real-Time & MultiMedia Lab
Code Migration
Real-Time & MultiMedia Lab
Migration and Local Resources
Resource-to machine binding
Process-toresource
binding
By identifier
By value
By type
Unattached
Fastened
Fixed
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)
GR: Establish a global systemwide reference
MV: Move the Resource
CP: Copy the value of the resource
RB: Rebind process to locally available resource
•
Actions to be taken with respect to the references to local resources when
migrating code to another machine.
Real-Time & MultiMedia Lab
Migration in Heterogeneous Systems
• Requirements:
 Platform supported: code segment may be recompiled to be executed in new
platform
 Ensure the execution segment can be represented at each platform properly.
• Solutions:
• Weak mobility: no runtime information needs to be transferred => just
recompile the source code
• Strong mobility: segment is highly dependent on the plaform => migration
stack: a copy of the program stack in a machine-independent way.(C, Java)
• Scenario:
• Migration can take place only when a next subroutine is called.
• When subroutine is called: marshalled data are pushed onto the migration
stack along with identifier for the called subroutine & the return label
• Then all global program-specific data are also marshalled (current stack &
machine-specific data are ignored)
Real-Time & MultiMedia Lab
Software Agents
• An agent (or a software agent) is an autonomous process capable
of reacting to, and initiating changes in, its environment, possibly
in collaboration with users and other agents.
• One more attempt:
– Self contained processes that run in the background on a client or server
and that perform useful functions for a specific user/owner
• Feature that make agents more than a process is its capability to act
on its own and take initiative where appropriate. Agents can be
classified on various functionality and purpose:
–
–
–
–
Collaborative agent
Mobile agent
Interface agent
Information agent
Real-Time & MultiMedia Lab
Software Agents in Distributed Systems
Property
Common 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
Yes
Can 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
Some important properties by which different types of
agents can be distinguished.
Real-Time & MultiMedia Lab
Agent Technology
• The general model of an agent platform (adapted from [fipa98-mgt]).
Real-Time & MultiMedia Lab
Agent Communication Languages
•
Components of a message
Real-Time & MultiMedia Lab
Agent Communication Languages (ACL)
•
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 source
Reference to source
Real-Time & MultiMedia Lab
Message Example (ACL)
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)
• A simple example of a FIPA ACL message sent between two agents using
Prolog to express genealogy information.
Real-Time & MultiMedia Lab
Question & Answer
Thank you!!!
Real-Time & MultiMedia Lab