Processes

1. Processes Muhammad Rafi Real-Time & MultiMedia Lab

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

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

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

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

6. Thread Elaboration • A set of threads share the same address space • User Level • Thread Library executed in user mode • Cheap to manage Thread • Easy Context switching • Kernel Level • Kernal Control schedule of thread • Expensive to manage Threads and Context switch • Kernel Intervention Real-Time & MultiMedia Lab

7. Light-Weight Processes(LWPs) • Support for hybrid approach (user-lever 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

8. 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 Implementation of LWPs Real-Time & MultiMedia Lab

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

10. Threads:Process Threads:Process Description Description Example Systems Example Systems Traditional UNIX implementations 1:1 1:M Each thread of execution is a unique process with its own address space and resources. A thread may migrate from one process environment to another. This allows a thread to be easily moved among distinct systems. Ra (Clouds), Emerald A process defines an address space and dynamic resource ownership. Multiple threads may be created and executed within that process. M:1 Windows NT, Solaris, OS/2, OS/390, MACH TRIX M:M Combines attributes of M:1 and 1:M cases Real-Time & MultiMedia Lab

11. Process & Thread In Windows 2000 Real-Time & MultiMedia Lab

12. Process Life Cycle in Windows 2000 Real-Time & MultiMedia Lab

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

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

15. 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 Real-Time & MultiMedia Lab

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

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

18. X-Window System Real-Time & MultiMedia Lab

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

20. 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) -Solution1: 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

21. 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 Code (methods) Data Object Real-Time & MultiMedia Lab

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

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

24. 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? • Performance • Load balancing • Exploiting parallel environment • Minimization communication and computation cycles • Flexibility • Security may be a threat? Real-Time & MultiMedia Lab

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

26. Code Migration Real-Time & MultiMedia Lab

27. Migration and Local Resources 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 • Actions to be taken with respect to the references to local resources when migrating code to another machine. Real-Time & MultiMedia Lab

28. 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-independentway.(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

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

30. Software Agents in Distributed Systems Some important properties by which different types of agents can be distinguished. Real-Time & MultiMedia Lab

31. Agent Technology • The general model of an agent platform (adapted from [fipa98-mgt]). Real-Time & MultiMedia Lab

32. Agent Communication Languages • Components of a message Real-Time & MultiMedia Lab

33. 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. Real-Time & MultiMedia Lab

34. Message Example (ACL) • A simple example of a FIPA ACL message sent between two agents using Prolog to express genealogy information. Real-Time & MultiMedia Lab

35. Question & Answer Thank you!!! Real-Time & MultiMedia Lab