1. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 1 Distribuerede systemer – 19. februar 2001 Presentation based on slides by Coulouris et al, modified by Jens B Jorgensen

2. 2 Chapter 6: Operating System Support From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edition 3, © Addison-Wesley 2001

3. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 3 Operating systems - basics zProvide problem-oriented abstractions of the underlying physical resources – the processors, communications, and storage media. zExamples: UNIX, Windows NT. zNetwork operating systems: yCan be used to access remote resources. yNodes retain autonomy in managing their own processing resources. yUsers can remotely log in to another computer. zDistributed operating systems: yUsers are never concerned with where their programs run. yUsers are never concerned with the location of resources. ySingle system image.

4. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 4 Operating systems – combined with middleware zNo distributed operating systems in generel use. zCombination of middleware and network operating systems provides a balance between: yRequirement for autonomy. yNetwork-transparent resource access. zThe operating system running at a node provides abstractions for local hardware resources. zThe middleware provides mechanisms for remote invocations between objects or processes at the nodes.

5. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 5 Operating systems - system layers

6. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 6 Operating systems – components of interest zKernel: A program that always runs and has complete privileges for the physical resources on its host computer. zServer processes: Manage resources (together with the kernel) and present clients with an interface to the resources. zClient processes: Access resources.

7. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 7 Operating system – requirements to kernel and server processes zEncapsulation: They should provide a useful service interface to their resources – that is, a set of operations that meet their clients’ needs. zProtection: Resources require protection from illegitimate accesses. zConcurrent processing: Clients may share resources and access them concurrently. Resource managers are responsible for achieving concurrency transparency.

8. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 8 Operating system – invocation-related tasks zCommunication: Operation parameters and results have to be passed to and from resource managers, over a network or within a computer. zScheduling: When an operation is invoked, its processing must be scheduled within the kernel or server.

9. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 9 Operating systems - core functionality (1)

10. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 10 Operating systems - core functionality (2) zProcess manager: Handles the creation of and operations upon processes. zThread manager: Thread creation, synchronization, and scheduling. zCommunication manager: Communication between threads attached to different processes on the same computer. zMemory manager: Management of physical and virtual memory. zSupervisor: Dispatching of interrupts, system call traps, etc.

11. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 11 Operating systems - protection zResources require protection from illegitimate access. zUse type-safe programming languages. zEmploy hardware support.

12. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 12 Operating systems – the kernel zControls the memory management unit and processor registers so that no other code may access the machine’s physical resources except in acceptable ways. zRuns with processor in supervisor/privileged mode (other processes in user/unprivileged mode). zSets up address spaces to protect itself and other processes from the accesses of an aberrant process. zTransfer from user-level to kernel’s address space via exceptions, such as system call traps.

13. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 13 Processes - processes and threads zProcess: Execution environment together with one or more threads. zThread: Operating system abstraction of an activity. zExecution environment includes: yAn address space. yThread synchronization and communication resources such as semaphores and communication interfaces. yHigher-level resources such as open files and windows. zThreads may share an execution environment. zAn execution environment provides protection from threads outside it.

14. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 14 Processes – creation of a new process zChoice of process host: yTransfer policy: Situate new process locally or remotely? yLocation policy: Which node should host new process? yStatic location policy. yAdaptive location policy. yLoad-sharing. zCreation of a new execution environment: yAddress space is of statically defined format. yAddress space defined with respect to existing execution environment.

15. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 15 Threads – why? zImprove performance! zExecution environments normally expensive to create and manage. zUtilize parallelism. zExample: yClient-server. yProcessing of each request takes 2 millisecond. yDisk access takes 8 milliseconds. y100 client requests per second with one thread. yMore client request per second with more threads (up to 500 requests per second – with caching).

16. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 16 Threads - worker pool architecture Server N threads Input-output Client Thread 2 makes T1 Thread 1 requests to server generates results Requests Receipt & queuing Fixed pool of ‘worker’ threads, I/O thread, shared request queue; Inflexible, high level of switching between the I/O and worker threads.

17. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 17 Threads – threads-per-request architecture remote workers I/O objects I/O thread spawns a new worker thread for each request, worker destroys itself when job is done; no contention for shared queue, higher throughput, overhead in thread creation and destruction.

18. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 18 Threads – thread-per-connection architecture remote per-connection threads objects A thread associated with each connection; lower thread-management overhead than per-request, some threads may be idle while others have outstanding requests.

19. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 19 Thread – threads-per-object architecture remote I/O per-object threads objects A thread associated with each remote object; lower thread-management overhead than per-request, some threads may be idle while others have outstanding requests.

20. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 20 Threads – threads in clients Server N threads Input-output Client Thread 2 makes T1 Thread 1 requests to server generates results Requests Receipt & queuing

21. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 21 Threads – threads versus multiple processes zCreating a new thread within an existing process is cheaper than creating a process. zSwitching to a different thread within the same process is cheaper than switching between threads belonging to different processes. zThreads within a process may share data and other resources conveniently and efficiently compared with separate processes. zThreads within a process are not protected from one another.

22. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 22 Threads – programming issues zThread lifetimes zThread synchronization. zThread scheduling. zThreads implementation.

23. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 23 Threads - Java thread constructor and management methods Thread(ThreadGroup group, Runnable target, String name) Creates a new thread in the SUSPENDED state, which will belong to group and be identified as name; the thread will execute the run() method of target. setPriority(int newPriority), getPriority() Set and return the thread’s priority. run() A thread executes the run() method of its target object, if it has one, and otherwise its own run() method (Thread implements Runnable). start() Change the state of the thread from SUSPENDED to RUNNABLE. sleep(int millisecs) Cause the thread to enter the SUSPENDED state for the specified time. yield() Enter the READY state and invoke the scheduler. destroy() Destroy the thread.

24. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 24 Communication and invocation – basic questions zWhat communication primitives does the OS supply? zWhich protocols does it support and how open is the communication implementation? zWhat steps are taken to make communication as efficient as possible? zWhat support is provided for high-latency and disconnected operations?

25. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 25 Communication and invocation – invocation performance zInvocation performance a critical factor in distributed system design. zSoftware overheads often predominate over network bandwidth (LAN). zIssues: ySynchronous or asynchronous? yInvolves a domain transition? yInvolves network communication? yInvolves thread scheduling and switching?

26. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 26 Communication and invocation - invocations between address spaces

27. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 27 Communication and invocation - RPC delay against parameter size

28. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 28 Communication and invocation – times for serialized and concurrent invocations

29. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 29 Operating system architecture – basic requirements zRun only that system software at each computer that is necessary for it to carry out its particular role in the system architecture. zAllow the software (and the computer) implementing any particular service to be changed independently of other facilities. zAllow for alternatives of the same service to be provided, when this is required to suit different users or applications. zIntroduce new services without harming the integrity of existing ones.

30. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 30 Operating system architecture – monolithic kernels and microkernels (1) zDiffers primarily in the decision as to what functionality belongs in the kernel and what is to be left to server processes that can be dynamically loaded to run on top of it. zMonolithic: Massive, undifferentiated, intractable. zMicrokernel: Provides only the most basic abstractions, principally address spaces, threads and local interprocess communication; all other system services are provided by servers that are dynamically loaded.

31. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 31 Operating system architecture - monolithic kernel and microkernel (2)

32. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 32 Operating system architecture - the role of the microkernel

33. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 33 Summary zOperating systems. zProcesses. zThreads. zCommunication and invocation. zOperating system architectures.