1 / 108

Processes

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.

lonna
Download Presentation

Processes

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Processes Chapter 3

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

  3. Chapter 3 ProcessPart 1 THREAD

  4. Process at a glance

  5. Process Process Control Block (PCB)

  6. Thread

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

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

  9. Thread Implementation-LWP (1) Combining kernel-level lightweight processes and user-level threads.

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

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

  12. 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)

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

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

  15. 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)

  16. Multithreaded Servers (2) A multithreaded server organized in a dispatcher/worker model.

  17. Multithreaded Servers (3) Three ways to construct a server. Back to Agenda

  18. Clients and Servers

  19. Clients Main role of clients is: to interact with human user and remote server -User Interface (UI): -Client-side software: UI + components for achieving transparent

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

  21. User Interface The X-Window System The basic organization of the X Window System

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

  23. Common interface 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.

  24. Servers

  25. 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?

  26. 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)

  27. 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)

  28. Servers: General Design Issues 3.7 • Client-to-server binding using a daemon as in DCE • Client-to-server binding using a superserver as in UNIX

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

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

  31. 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 Object Object Object Code (methods) Data Object

  32. Invoking Objects The Object Server is needed to know: -Which code is execute? -On which data is should operate?

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

  34. 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?

  35. Memory Allocation • Each object has its own memory segment • Objects can share memory segments • Security? • Memory resources?

  36. Threads • One thread in the server • Several threads in the server • Separate thread for each object • Separate thread for each request • Concurrent access?

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

  38. Object Adapters (Wrappers) Organization of an object server supporting different activation policies. Back to agenda

  39. Chapter 3 ProcessPart 4. Code migration

  40. 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…})

  41. Why migrate code? (1) Main Reason: Better performance of overall system

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

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

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

  45. Models for Code Migration Transfer only the code segment => simplicity anonymous Execution segment can be transferred as well (running process can be stopped & moved to another machine to resume execution) Alternatives for code migration.

  46. 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…}) anonymous Execution segment can be transferred as well (running process can be stopped & moved to another machine to resume execution) Alternatives for code migration.

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

More Related