1 Chapter 3 Processes Dowon Cho (RTMM Lab) & Jongwon Lee (SE Lab)
-
Upload
john-reynolds -
Category
Documents
-
view
216 -
download
0
Transcript of 1 Chapter 3 Processes Dowon Cho (RTMM Lab) & Jongwon Lee (SE Lab)
1
Chapter 3
Processes
Dowon Cho (RTMM Lab)&
Jongwon Lee (SE Lab)
2
Index
• Threads
• Clients
• Servers
3
Processes
Process Control Block (PCB)
4
Processes (cont.)• Process
– Program in execution
• OS creates an extended machine multiple virtual CPUs
• OS keeps track of all processes (process tables)
• Processes are independent of one another
• OS protects processes from one another (with h/w support)
5
Processes (cont.)
• Process allow the OS to overlap I/O and computation, creating an efficient system
• Overhead– Process creation– Context switching – Swapping– All required kernel intervention
6
Threads
Thread Concept
7
Threads (cont.)
• Threads and Processes– Threads are not protected from each other
• Require care from developers
• Context switching is cheaper
• System call– Process must be blocked– Thread may still proceed
8
Threads (cont.)• Thread is executed entirely in user mode
• Cheap to manage threads– Create: setup a stack– Destroy: free up memory
• Context switch requires few instructions– Save CPU registers– Execution based on program logic
9
Threads (cont.)• Kernel is aware of and schedules threads
• It is expensive to manage threads
• It is expensive to context switch
• Almost expensive as using processes
10
Threads (cont.)
• Light-Weight Processes (LWP)– Support for hybrid (user-level and Kernel)
threads
– A process contains several LWPs
– Developer: creates multi-threaded application
– System: Maps threads to LWPs for execution
11
Threads (cont.)
Combining kernel-level lightweight processes and user-level threads.
12
Threads (cont.)• Each LWP offers a virtual CPU
• LWPs are created by system calls
• Thread table is kept in user space
• Thread table is shared by all LWPs
• LWPs switch context between threads
13
Threads (cont.)• 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
14
Threads (cont.)• LWP advantages
– Cheap thread management– A blocking system call may not suspend
the whole process– LWPs are transparent to the application– LWPs can be easily mapped to different
CPUs
15
Clients
• Main role of clients– To interact with human user and remote
server
• Client side software– User Interface (UI) + components for
achieving transparent
16
Clients (cont.)
• X-window system
17
Clients (cont.)• Goal
– Generally used to control bit-mapped terminals
• X-kernels– Contains all terminal-specific devices– Offer relative low-level interface for controlling the
screen– Capturing events from the keyboard and mouse
• 4 major components– X servers: Managing the screen, mouse and keyboard– X client: the application (where the real work gets done)– X protocol: Client/server communication– X library: the programming interface
18
Servers
• Design issues– How to organize the server– How client contacts with server– Whether and how a server can be
interrupted– Whether a stateful or stateless server
19
Servers (cont.)
• How to organize the server– Iterative server (sequential server)
• Itself handle the request and return a response to the request.
– Concurrent server • It does not handle the request but passes it
into threads
20
Servers (cont.)• How client contacts with server
– Clients sent the request to the endpoint (port) of the server• Approach 1
– Endpoint is assigned with the well-know service
• Approach 2– Not pre-assigned endpoint
» Solution 1: Each server has a special daemon to keep tracks of the current endpoint of each service
» Solution 2: using a single super server
21
Servers (cont.)
a) Client-to-server binding using a daemon as in DCEb) Client-to-server binding using a superserver as in UNIX
22
Servers (cont.)• Whether and how a server can be interrupted
– Approach 1• Client suddenly exits the application and restarts
immediately– Server thinks that the client had crashed and will tear down
the connection
– Approach 2• Send out-of-band data (which is processed 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
23
Servers (cont.)
• Whether a stateful or stateless server– Stateful server
• It maintains information on its clients (ex. File server)
– Stateless server• It does not keep information on the state of
its client• It can change its own state without having to
inform any client
24
Servers (cont.)
• Object Server– Tailored for distributed objects support– Provides environment for objects
• Not a service by itself
– Services are provided by objects– Easy to add services (by adding objects)
25
Servers (cont.)
Object server concept
Object
Data Code (methods)
Object server
Object Object
Object
26
Servers (cont.)
• Activation Policies– Decisions on how to invoke objects– All objects are alike
• Inflexible
– Objects differ and require different policies• Object type• Memory allocation• Threading
27
Servers (cont.)
• Each object has its own memory segment
• Objects can share memory segments
• Security?
• Memory resources?
28
Servers (cont.)
• One thread in the server
• Several threads in the server
• Separate thread for each object
• Separate thread for each request
• Concurrent access?
29
Servers (cont.)
• Object Adapters (wrappers)– 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
30
Servers (cont.)
• Object Adapters (wrappers)
31
Part 4. Code Migration
32
Code Migration
• Code Migration = moving processes between machines
• Process = 3 segments- Code segment (the code) : is the part that contains the set of instructions that make up the program
- Resource segment (references to external resources {files, printers, devices, other processes, etc})- Execution segment (current execution state of a process {stack, program counter, registers, private data…})
33
Why migrate code? (1)
• Main Reason:
• Better performance of overall systemIf processes are moved from heavily-loaded to lightly-loaded machines, overall system performance can be improved.
34
Why migrate code? (2)
Load-Balancing (for multiprocessors)- Move process from over-utilized to under-utilized CPU- Load distribution algorithms by which decisions are made concerning the allocation and redistribution of tasks with respect to a set of processors
Minimizing Communication Costs Exploiting parallelism
- Examples: - client application needs to do many database operations involving large quantities
of data => ship part of the client application to the server => send only the results across the network.
- Interactive database applications: client needs to fill in forms => ship part of the server application to the client
- Searching information in the Web by a small mobile prog. => make some copies of such a prog. => send each off to different sites
35
Why migrate code? (3)
Besides improving performance: Flexibility
Clients need not have all the S/W pre-installed: download on demand, then dispose.
- Remote object stub in Java
- Java applets
Security: Can you trust any code? (both client & server)
Need a standardized protocol for downloading & initializing code
Guarantee that downloaded code can be executed
36
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.
Can be executed on the Client’s machine
Require the protocol for downloading and initializing code
37
Models for Code Migration
• Alternatives for code migration.
Transfer only the Code segment =>simplicityTransferred program only started from its initial state. e.g.Java applet.
Execution segment can be transferred as well (running process can be stopped & moved to another machine to resume execution).
Initiated at the machine where the code currently resides or is being executed, Uploading program to compute server.e.g, Search programRequire registration & authentication The initiative for code migration is taken by target machine.
e.g, Java applet
There is no need to start separate process, thereby avoidingCommunication at the target machine.Protected against malicious or inadvertent code execution
38
GR: Establish a global systemwide reference
MV: Move the Resource
CP: Copy the value of the resource
RB: Rebind process to locally available resource
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
Binding by identifier: e.g, uses a URL for Website or IP address for FTP server. Binding by value: e.g, C or Java standard librariesBinding by type: local devices such as monitors, printers,
Unattached resources: can easily moved between different machines, typically (data) files associated only with the program that is to be migrated. Fastened resources: e.g, local databases, complete Websites (moveable but high costs)Fixed resources: local devices
39
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 platform => migration stack: a copy of the program stack in a machine-independent way.(C, Java)
40
Migration in Heterogeneous Systems
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)
41
Migration in Heterogeneous Systems
• The principle of maintaining a migration stack to support migration of an execution segment in a heterogeneous environment
end
42
Part 5. Software Agents
43
Software Agents
• Definition:• Is as an autonomous process capable of
reacting to, and changes in, its environment, possibly in collaboration with users and other agents
44
Software Agents
• Taxonomy:
Collaborative Agent : an agent that forms part of a multiagent system, in which agents seek to achieve some common goal through collaboration. e.g Cyber-meeting system
Mobile Agent : simply an agent having the capability to move between different machines.
45
Software Agents
• Taxonomy:
Interface Agent : assist an end user in the use of one or more application.
Information Agent : manage information from many different sources. ordering, filtering, collating information. e.g e-mail agent
46
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
47
Agent Technology
• The general model of an agent platform (adapted from [fipa98-mgt]).
Management Component: provides the facilities for creating and deleting agents
Directory Service: describe of agent’s service by attributes
Agent Communication Channel: take care of of all communication between different agent platform
48
Agent Communication Languages
• Definition:
• Communication between agents takes place by means
• of an application-level communication protocol which is
• referred to as an agent communication language.
49
Agent Communication Languages
• Components of a message
50
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-IFQuery 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
51
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)