1 / 108

Processes - PowerPoint PPT Presentation

  • Uploaded on

Processes. Chapter 3. Agenda. 1- Threads (N.Q.Hung) 2-Clients (L.X.Hung) 3-Servers (L.X.Hung) 4-Code Migration (N.Q.Hung) 5-Software Agent (L.X.Hung). Chapter 3 Process Part 1 THREAD. Process at a glance. Process. Process Control Block (PCB). Thread. Kernel-Level Threads.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Processes' - lonna

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript


Chapter 3


1-Threads (N.Q.Hung)

2-Clients (L.X.Hung)

3-Servers (L.X.Hung)

4-Code Migration (N.Q.Hung)

5-Software Agent (L.X.Hung)

Chapter 3 process part 1 thread
Chapter 3 ProcessPart 1 THREAD


Process Control Block (PCB)

Kernel level threads
Kernel-Level Threads

  • Kernel is aware of and schedules threads

  • A blocking system call, will not block all peer threads

  • Expensive to manage threads

  • Expensive context switch

  • Kernel Intervention

  • Maybe as expensive as using processes!!

Light weight processes lwp
Light-Weight Processes (LWP)

  • Support for hybrid (user-level and Kernel) threads

  • A process contains several LWPs

  • Developer: creates multi-threaded applications

  • System: Maps threads to LWPs for execution

Thread implementation lwp 1
Thread Implementation-LWP (1)

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

Thread implementation lwp 2
Thread Implementation - LWP (2)

  • 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

Thread implementation lwp 3
Thread Implementation - LWP (3)

  • 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

Lwp advantages
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

  • Managing LWPs is expensive (like kernel threads)

Threads and distributed systems
Threads and Distributed Systems

  • 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

Multi threaded clients
Multi-Threaded Clients

  • 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

  • Separate connection for each page component (HTML file, image, audio…)

  • Better: if server is horizontally distributed, data will be transferred in parallel

Multi threaded servers 1
Multi-Threaded Servers (1)

  • 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

  • Example: File Server (fig)

Multithreaded servers 2
Multithreaded Servers (2)

A multithreaded server organized in a dispatcher/worker model.

Multithreaded servers 3
Multithreaded Servers (3)

Three ways to construct a server.

Back to Agenda


Main role of clients is: to interact with human user and remote server

-User Interface (UI):

-Client-side software: UI + components for achieving transparent

User interface
User Interface

  • The 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

User interface1
User Interface

The X-Window System

The basic organization of the X Window System

Client side software for distribution transparency
Client-Side Software for Distribution Transparency

-UI is a small part of the client-side S/W

-Client S/W includes:

+Local processing

+Communication facilities: distribution transparency

+Replication transparency (next slide)

+Access transparency: client stub

+Location, migration, relocation transparency: naming

+Failure transparency

Client side software for distribution transparency1



to Service

Client or

Server side

Client-Side Software for Distribution Transparency

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

Servers general design issues
Servers: General Design Issues

1-Organize of server?

2-How client contacts with server?

3-Whether and how a server can be interrupt?

4-Stateful or Stateless server?

Servers general design issues1
Servers: General Design Issues

1-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)

Servers general design issues2
Servers: General Design Issues

  • 2-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)

Servers general design issues3
Servers: General Design Issues


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

  • Client-to-server binding using a superserver as in UNIX

Servers general design issues4
Servers: General Design Issues

3- 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)

    -Solution1: Out-of-band data is listened by separated endpoint.

    -Solution 2: Out-of-band data is sent across the same connection with urgent

Servers general design issues5
Servers: General Design Issues

4- Stateful 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

Stateful server:

-Does maintain information on its clients.

Ex: File server

Object servers
Object Servers

-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




Code (methods)



Invoking objects
Invoking Objects

The Object Server is needed to know:

-Which code is execute?

-On which data is should operate?

Invoking objects1
Invoking Objects

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 Objects

  • Create at the first invocation request and destroy when clients are no longer bound to it

  • Create all transient objects when server is initialized

  • Server resources?

  • Invocation time?

Memory Allocation

  • Each object has its own memory segment

  • Objects can share memory segments

  • Security?

  • Memory resources?


  • One thread in the server

  • Several threads in the server

  • Separate thread for each object

  • Separate thread for each request

  • Concurrent access?

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

Object adapters wrappers
Object Adapters (Wrappers)

Organization of an object server supporting different activation policies.

Back to agenda

Chapter 3 process part 4 code migration
Chapter 3 ProcessPart 4. Code migration

Code migration
Code Migration

  • Code Migration = moving processes between machines

  • Process = 3 segments

    • Text segment (the code)

    • Resource segment (refs to external resources {files, printers, devices, other processes, etc})

    • Execution segment (state of a process {stack, program counter, registers, private data…})

Why migrate code 1
Why migrate code? (1)

Main Reason:

Better performance of overall system

Why migrate code 2
Why migrate code? (2)

  • Load-Balancing (for multiprocessors)

    • Move process from over-utilized to under-utilized CPU

  • 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

      • 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. => send some copies of such a prog. off to different sites

Why migrate code 3
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

Scenario of migrating code
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.

Models for code migration
Models for Code Migration

Transfer only the code segment => simplicity


Execution segment can be transferred as well (running process can be stopped & moved to another machine to resume execution)

Alternatives for code migration.

Models for code migration1
Models for Code Migration

Require registration & authentication at the server

Eg: search prog., uploading programs to a compute server

Transfer only the code segment => simplicity

  • Process = 3 segmnts

    • Text segment (the code)

    • Resource segment (refs to external resources {files, printers, devices, other processes, etc})

    • Execution segment (state of a process {stack, program counter, registers, private data…})


Execution segment can be transferred as well (running process can be stopped & moved to another machine to resume execution)

Alternatives for code migration.

Migration and local resources
Migration and Local Resources

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 libraries

Binding by type: local devices such as monitors, printers, …

Resource-to machine binding

Process-to-resource binding

GR: Establish a global systemwide reference

MV: Move the Resource

CP: Copy the value of the resource

RB: Rebind process to locally available resource

Unattached resources: can easily moved between different machines, typically (data) files associated only with the program that is to be migrated.

Fastened resources: eg, local databases, complete Websites (moveable but high costs)

Fixed resources: local devices

Actions to be taken with respect to the references to local resources when migrating code to another machine.

Migration in heterogeneous systems
Migration in Heterogeneous Systems

  • 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)

  • 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.

Migration in heterogeneous systems1
Migration in Heterogeneous Systems


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


Software agents1
Software Agents


Is as an autonomous process capable of reacting to, and changes in, its environment, possibly in collaboration with users and other agents

Software agents in distributed systems
Software Agents in Distributed Systems

Some important properties by which different types of agents can be distinguished.

Agent technology
Agent Technology

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

Agent communication languages 1
Agent Communication Languages (1)

Components of a message

Agent communication languages 11
Agent Communication Languages (1)

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.

Agent communication languages 2
Agent Communication Languages (2)

A simple example of a FIPA ACL message sent between two agents using Prolog to express genealogy information.

End of chapter 3
End of chapter 3

Thank you for joining us!



Chapter 4


1.Definition of Names, Identifiers, and Address

2.Name Space, Name Resolution

3.Implementation of Name Space and Name Resolution

4.Another Case: Mobile Entities

5.Solutions for the Problem of Mobile Entities

6.Problem of Removing Unreferenced Entities

7.Solutions for how to remove unreferenced Entities




Name resolution

Name space


Of Name space

Implementation Of

Name resolution


Mobile Entities

Solution for Mobile locating


Remove unreferenced entities


  • Name : a string of bitsor characters =>refer to an entity

  • Address

    • name of an access point

  • Identifiers

  • identifier is a name that has the following properties:

    • An identifier refers to at most one entity.

    • Each entity is referred to by at most one identifier.

    • An identifier always refers to the same entity.

  • Human-friendly name

    • Used by human

Name spaces
Name Spaces

  • Name spaces

    • Names are organized into name space

  • How is name space represented?

  • leaf node

    • represents a named entity

    • has no outgoing edges.

  • directory node

    • has a number of outgoing edges

    • each outgoing edges labeled with a name

Example name spaces
Example: Name Spaces

Root (node)

Directory table=>

  • A general naming graph with a single root node.

Example organization on disk
Example: Organization on disk

How to organize name space on disk?

  • The general organization of the UNIX file system implementation on a logical disk of contiguous disk blocks.

Name resolution
Name Resolution

  • name resolution

    • process of looking up a name

  • How does name resolution work?

  • Example :

  • Pathname : N:<label-1,label-2,…,label-n>

    • Label-1 : return the identifier of the node

    • Label-n : return the content of that node

  • Problem: how and where to start name resolution ?

    • Closure Mechanism & the environment variables

Name resolution1
Name Resolution

  • What is link?

    • Through a path to arrive the node.

  • Introduction:

  • Alias: an alias is another name for the same entity

    • Condition: In file system

  • Two different way to implement alias:

    • allow multiple absolute paths names to refer to the same node  Hard link

    • represent an entity by a leaf node, but instead of storing the address or state of that entity, the node stores an absolute path name Symbolic link

Example symbolic link
Example: symbolic link

  • The concept of a symbolic link explained in a naming graph.

Name resolution2
Name Resolution

  • What is mount?

    • To make a file system available for access.

  • Purpose:

    • Transparent way for name resolution with different name spaces

  • Introduction:

    • Condition:In mounted file system

  • mount point

    • Directory node,in the name space, store the necessary information reference to mounting point

  • mounting point

    • Directory node in the foreign name space, which is referenced by the mount point

Name resolution3
Name Resolution

  • Necessary information:

    • The name of an access protocol.

    • The name of the server.

    • The name of the mounting point.

  • For example:

  • ”nfs://”

    • nfs  name of access protocol

    •  name of server

    • home/steen  name of mounting point

Example mounting 1
Example: Mounting(1)

Mount point

Mounting point

  • Mounting remote name spaces through a specific process protocol.

Name resolution4
Name Resolution

  • Another way for Mounting

    • Add a new root node and to make the existing root nodes its children

  • Problem:

    • Existing names need to be changed

      • For example:

        • “/home/steen”  “/vu/home/steen”

    • =>

    • If thousands of name spaces are merged, this approach will eventually lead to performance problems.

Implementation of name space
Implementation of Name Space

  • Name Space Distribution

  • Base on :frequency of change

  • Global layer

    • highest-level nodes and other directory nodes logically close to the root

  • Administrational layer

    • directory nodes that are managed within a single organization

  • Managerial layer

    • consists of nodes that may typically change regularly

Example name space distribution
Example: Name Space Distribution

  • An example partitioning of the DNS name space, including Internet-accessible files, into three layers.

Comparison name space distribution
Comparison:Name Space Distribution

  • A comparison between name servers for implementing nodes from a large-scale name space partitioned into a global layer, as an administrational layer, and a managerial layer.

Implementation of name resolution
Implementation of Name Resolution

  • There are two ways to implement name resolution.

  • Iterative name resolution

    • Server will resolve the path name as far as it can, and return each intermediate result to the client.

  • Recursive name resolution

    • A name server passes the result to the next name server which found by it.

    • Drawback:

      • put a higher performance demand on each name server

    • Advantage:

      • Caching results is more effective compared to iterative

      • Communication costs may be reduced

Implementation of name resolution1
Implementation of Name Resolution

  • The principle of iterative name resolution.

Implementation of name resolution2
Implementation of Name Resolution

  • The principle of recursive name resolution.

Comparison with the costs
Comparison with the Costs

Communication costs are dictated by the message exchange between the client’s host and the server.

  • The comparison between recursive and iterative name resolution with respect to communication costs.

Mobile entities
Mobile Entities

  • Naming versus Locating Entities

  • Problem of naming services:

    • Direct mapping between human-friendly names and the addresses of entities

    • Each time a name or an address changes, the mapping needs to change

  • Solution:

  • To separate naming from locating entities by introducing identifiers

Mobile entities1
Mobile Entities

Naming versus Locating Entities

  • Direct, single level mapping between names and addresses.

  • Two-level mapping using identifies.

Solution for locating entity
Solution for Locating Entity

  • For local-area networks

  • Broadcasting:


    • 1.Broadcast a message which containing the identifier of the entity to each machine

    • 2. Each machine is requested to check whether it has that entity

    • 3. Only the machines that can offer an access point for the entity send a reply message containing the address of that access point.

  • Multicasting: Base on the broadcasting

    • Add a condition: only a restricted group of hosts receives the message.

Solution for locating entity1
Solution for Locating Entity

  • Forwarding Pointers

    • Key idea:

    • Whenever an object moves from address space A to B, it leaves behind a proxy in its place in A and installs a skeleton that refers to it in B.

    • How does forwarding pointer work?

    • Each forwarding pointer is implemented as a (proxy, skeleton) pair.

    • A skeleton contains either a local reference to the actual object or a local reference to a proxy for that object.

    • Skeletons act as entry items for remote references, and proxies as exit items.

Solution for locating entity2
Solution for Locating Entity

  • Main advantage:

    as soon as an entity can be located

  • Drawback:

    1. A chain can be very long  be expensive

    2. All intermediate locations in a chain have to maintain their part of the chain as long as needed

    3. The chain is easy to be broken.

Example forwarding pointers
Example: Forwarding Pointers

  • The principle of forwarding pointers using (proxy, skeleton) pairs.

Solution for locating entity3
Solution for Locating Entity

  • Home-Based Approaches (two-tiered scheme)

    • Purpose: support mobile entities in large-scale networks

    • Introduction:

      • Home location

        • keep track of the current location of an entity

      • Home agent

        • 1. Each mobile host uses a fixed IP address.

        • 2. All communication to that IP address is initially directed to the mobile host’s home agent.

    • Drawback:

      • Communication latency

      • Ensure the home location always exists

Solution for locating entity4
Solution for Locating Entity

Hierarchical Approaches

  • Leaf domain: a lowest-level domain, corresponds to a local-network in a computer network or a cell in a mobile telephone network.

  • Hierarchical organization of a location service into domains, each having an associated directory node.

Example an entity having two addresses
Example: an entity having two addresses

  • Location record: keep track of the whereabouts of an entity

  • An example of storing information of an entity having two addresses in different leaf domains.

Solution for locating entity5
Solution for Locating Entity


Lookup Operation

  • Looking up a location in a hierarchically organized location service.

Pointer caches
Pointer Caches

  • Purpose:

  • Store lookup results in local caches can be highly effective

  • Lookup operation ,combined with pointer caching

  • steps:

    • 1. Requires inspecting the local pointer cache, leading directly to the appropriate directory node.

    • 2. Involves requesting that node to return the current address of E.

Example pointer caches
Example: Pointer Caches

  • Caching a reference to a directory node of the lowest-level domain in which an entity will reside most of the time.

Removing unreferenced entities
Removing Unreferenced Entities

  • Garbage:

    • An entity can no longer be accessed should be removed.We consider this entity as garbage.

  • Unreferenced Entities

    • An object can be accessed only if there is a remote reference to it.

    • An object for which no remote reference exists should be removed from the system.

    • On the other hand, having a remote reference to an object does not mean that the object will ever be accessed.

Example unreferenced objects
Example: Unreferenced Objects

  • An example of a graph representing objects containing references to each other.

Method in uniprocessor system
Method in uniprocessor system

  • Reference Counting

    • A method to check whether an object can be deleted

    • Simply count the references to that object

    • As soon as the counter reaches zero, the object can be removed.

  • Problem:

    • 1. Falsely increment

    • 2.Increment the counter too late

Example falsely increment
Example: Falsely increment

When a process P create a reference to a remote object O, it installs a proxy p for O in its address space.

ACK: acknowledgement

Example increment the counter too late
Example: Increment the counter too late

Occurs when copying a remote reference to another process.

  • Copying a reference to another process and incrementing the counter too late

  • A solution.  performance problem

A different approach
A different approach

  • Reference Listing

    • skeleton maintains an list of all proxies that point to it

    • Property: Adding or removing proxies has no effect.

    • Advantage:

      • Does not require communication to be reliable

      • It is not necessary that duplicate messages can be detected and discarded

      • It is easier to keep the reference list consistent in the face of process failures

    • Drawback:

      • Scale badly if the skeleton needs to keep track of many reference.

Identifying unreachable entities
Identifying Unreachable Entities

  • Another case

  • Problem:

    • Entities may store reference to each other

    • But none of these entities can be reached from the root set

  • General solution:

    • All entities in a distributed system are traced.

    • This is done by Checking which entities can be reached from the root set and subsequently removing all others

Tracing in uniprocessor system
Tracing in uniprocessor system

  • Approach :

    • Mark-and-sweep

  • Mark

  • Entities are traced by following chains of references originating from entities in the root set.

  • Each entity that can be reached in this way is marked.

  • Sweep

  • Examining memory to locate entities that have not been marked.

  • Such entities are considered garbage that is to be removed.

  • Tracing in uniprocessor system1
    Tracing in uniprocessor system

    • Drawback:

    • “Stop-the-world”

      • All processes in the system first need to be synchronized,

      • Then each of them switches to collecting garbage,

      • After that they can all continue with their original work.

    • Scalability problem

      • In a distributed system, it needs to trace all entities

    • Solution:

      • Allow program execution to be interleaved with garbage collection

      • Divide into groups

    In large distributed system
    In large distributed system

    • Garbage collection take place within groups through a combination of mark-and-sweep and reference counting.

    End of chapter 4 thank you
    End of Chapter 4Thank you!