Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 OMSE 510: Computing Foundations 5: The Operating System Chris Gilmore Portland State University/OMSE.

Similar presentations


Presentation on theme: "1 OMSE 510: Computing Foundations 5: The Operating System Chris Gilmore Portland State University/OMSE."— Presentation transcript:

1 1 OMSE 510: Computing Foundations 5: The Operating System Chris Gilmore Portland State University/OMSE

2 2 Today The Operating System! Back to talking about software! Overview Process/Kernel Abstraction Timeslicing Process Scheduling

3 3 Computer System (Idealized) CPU Memory System Bus Disk Controller Disk

4 4 What is an operating system? Operating system --“is a program that controls the execution of application programs and acts as an interface between the user of a computer and the computer hardware” Narrow view Traditional computer with applications running on it (e.g. PCs, Workstations, Servers) Broad view Anything that needs to manage resources (e.g. router OS, embedded devices, pagers,...)

5 5 Two key OS functions Abstract Machine Hide details of the underlying hardware Provide “common” API to applications and services Simplifies application writing Resource Manager Controls accesses to “shared” resources CPU, memory, disks, network,... Allows for “global” policies to be implemented

6 6 Why is abstraction important? Without OSs and abstract interfaces a pplication writers program all device access directly load device command codes into device registers handle initialization, recalibration, sensing, timing etc for physical devices understand physical characteristics and layout control motors interpret return codes … etc Applications suffer severe code bloat! very complicated maintenance and upgrading writing this code once, and sharing it, is how OS began!

7 7 Providing abstraction via system calls Operating System Video Card CPU Monitor Printer Disk Memory Network Application Hardware

8 8 Providing abstraction via system calls Operating System Video Card CPU Monitor Printer Disk Memory Network Application Hardware System Calls: read(), open(), write(), mkdir(), kill()... Device Mgmt File System Network Comm. Process Mgmt Protection Security

9 9 OS as a resource manager Sharing resources among applications across space and time scheduling allocation Making efficient use of limited resources improving utilization minimizing overhead improving throughput/good put Protecting applications from each other enforcement of boundaries

10 10 Problems an OS must solve Time sharing the CPU among applications Space sharing the memory among applications Space sharing the disk among users Time sharing access to the disk Time sharing access to the network

11 11 More problems an OS must solve Protection of applications from each other of user data from other users of hardware/devices of the OS itself! The OS needs help from the hardware to accomplish these tasks!

12 12 Overview of computer system layers Hardware - CPU, memory, I/O devices - disk, network...

13 13 The OS is just a program! How can the OS cause application programs to run? How can applications programs cause the OS to run? How can the OS switch the CPU to run a different application and later resume the first one? How can the OS maintain control? In what ways can application code try to cheat? And how can the OS stop the cheating?

14 14 How can the OS invoke an application? The computer boots and begins running the OS fetch/decode/execute OS instructions OS can request user input to identify an application to run OS loads the address of the application’s starting instruction into the PC CPU fetches/decodes/executes the application’s instructions

15 15 How can applications invoke the OS? Trap instruction changes PC to point to an OS entry point instruction application calls a library procedure that includes the appropriate trap instruction fetch/decode/execute cycle begins at a specified OS entry point called a system call

16 16 How can the OS run a new application? To suspend execution of an application simply capture its memory state and processor state copy values of all registers into a data structure and save it to memory preserve the memory values of this application so it can be restarted later

17 17 How can OS guarantee to regain control? What if a running application doesn’t make a system call and hence hogs the CPU? timer interrupts! OS must register a future timer interrupt before it hands control of the CPU over to an application How can the OS avoid trampling on the processor state it wants to save? carefully written interrupt handlers!

18 18 What if the application tries to cheat? What stops the running application from disabling the future timer interrupt so that the OS can not regain control? the mode bit (in the PSW)! Certain instructions can only be executed when the mode bit is set manipulating timer interrupts setting the mode bit!...

19 19 What other ways are there to cheat? What stops the running application from modifying the OS? Memory protection! can only be set with mode bit set …. The OS must clear the mode bit before it hands control to an application! interrupts and trap instructions set the mode bit and transfer control to specific locations (in the OS)

20 20 Why its not quite that simple... Pipelined CPUs Superscalar CPUs Multi-level memory hierarchies Virtual memory Complexity of devices and buses Heterogeneity of hardware

21 21 Pipelined CPUs Fetch unit Decode unit Execute unit Execution of current instruction performed in parallel with decode of next instruction and fetch of the one after that

22 22 Superscalar CPUs Fetch unit Decode unit Execute unit Fetch unit Decode unit Execute unit Execute unit Holding buffer

23 23 What does this mean for the OS? Pipelined CPUs more complexity in capturing state of a running application more expensive to suspend and resume applications Superscalar CPUs even more complexity in capturing state of a running application even more expensive to suspend and resume applications More details, but fundamentally the same task

24 24 Terminology review - metric units The metric prefixes

25 25 The memory hierarchy 2GHz processor  0.5 ns Data/inst. cache  0.5ns – 10 ns, 64 kB- 1MB (this is where the CPU looks first!) Main memory  60 ns, 512 MB – 1GB Magnetic disk  10 ms, 160 Gbytes Tape  Longer than you want, less than magnetic disk!

26 26 Who manages the memory hierarchy? Movement of data from main memory to cache is under hardware control cache lines loaded on demand automatically replacement policy fixed by hardware Movement of data from cache to main memory can be affected by OS instructions for “flushing” the cache can be used to maintain consistency of main memory Movement of data among lower levels of the memory hierarchy is under direct control of the OS virtual memory page faults file system calls

27 27 OS implications of a memory hierarchy? How do you keep the contents of memory consistent across layers of the hierarchy? How do you allocate space at layers of the memory hierarchy “fairly” across different applications? How do you hide the latency of the slower subsystems? Main memory… yikes! Disk Tape How do you protect one application’s area of memory from other applications? How do you relocate an application in memory?

28 28 Summary/Quiz How does the OS solve these problems: Time sharing the CPU among applications? Space sharing the memory among applications? Space sharing the disk among users? Time sharing access to the disk? Time sharing access to the network? Protection of applications from each other? Protection of user data from other users? Protection of hardware/devices? Protection of the OS itself?

29 29 Section overview OS-Related Hardware & Software Memory protection and relocation Virtual memory & MMUs I/O & Interrupts Processes Process scheduling Process states Process hierarchies Process system calls in Unix

30 30 Memory protection and relocation... Memory protection (basic ideas) virtual vs physical addresses address range in each application starts at 0 “base register” used to convert each virtual address to a physical address before main memory is accessed address is compared to a “limit register” to keep memory references within bounds Relocation by changing the base register value Paged virtual memory same basic concept, but more powerful (and complex)

31 31 Base & Limit Registers (single & multiple)

32 32 Virtual memory and MMUs Memory management unit (MMU) hardware provided equivalent of base registers at the granularity of “pages” of memory, say 2kB, i.e., lots of them! supports relocation at page granularity applications need not occupy contiguous physical memory Memory protection limit registers don’t work in this context per-page and per-application protection registers Relocation and protection occur at CPU speeds!

33 33 What about I/O devices? Monitor Bus A simplified view of a computer system

34 34 Structure of a large Pentium system

35 35 How do programs interact with devices? Devices vs device controllers vs device drivers device drivers are part of the OS programs call the OS which calls the device driver Device drivers interact with device controllers either using special IO instructions or by reading/writing controller registers that appear as memory locations Why protect access to devices by accessing them indirectly via the OS?

36 36 How do devices interact with programs? Interrupts

37 37 Different types of interrupts Timer interrupts Allows OS to maintain control One way to keep track of time I/O interrupts Keyboard, mouse, disks, etc… Hardware failures Program generated (traps) Programming errors: seg. faults, divide by zero, etc. System calls like read(), write(), gettimeofday()

38 38 Timer interrupts OS can ask timer device to interrupt after a specified time period has elapse Interrupt invokes timer interrupt handler which invokes OS “scheduler” OS can take the opportunity to save the current application and restore a different one context switch

39 39 Why use traps for system calls? The Operating System is just a program! It must have the privilege to manipulate the hardware set base and limit registers for memory protection access devices set and clear mode bit to enable privilege If user programs execute with the mode bit clear, and do not have privilege to set it, how can they invoke the OS so that it can run with the mode bit set? That’s what traps do … set the mode bit and begin execution at a specific point in memory (in the OS!)

40 40 System calls System calls are the mechanism by which programs communicate with the O.S. Implemented via a TRAP instruction Example UNIX system calls: open(), read(), write(), close() kill(), signal() fork(), wait(), exec(), getpid() link(), unlink(), mount(), chdir() setuid(), getuid(), chown()

41 41 The inner workings of a system call User-level code Library code Process usercode {... read (file, buffer, n);... } Procedure read(file, buff, n) {... read(file, buff, n)... } _read: LOAD r1, @SP+2 LOAD r2, @SP+4 LOAD r3, @SP+6 TRAP Read_Call

42 42 Steps in making a system call

43 43 What about disks and file storage? Structure of a disk drive

44 44 Disks and file storage Manipulating the disk device is complicated hide some of the complexity behind disk controller, disk device driver Disk blocks are not a very user-friendly abstraction for storage contiguous allocation may be difficult for large data items how do you manage administrative information? One application should not (automatically) be able to access another application’s storage OS needs to provide a “file system”

45 45 File systems File system - an abstraction above disk blocks

46 46 What about networks? Network interfaces are just another kind of shared device/resource Need to hide complexity send and receive primitives, packets, interupts etc protocol layers Need to protect the device access via the OS Need to allocate resources fairly packet scheduling

47 47 The Process Concept Process – a program in execution Program description of how to perform an activity instructions and static data values Process a snapshot of a program in execution memory (program instructions, static and dynamic data values) CPU state (registers, PC, SP, etc) operating system state (open files, accounting statistics etc)

48 48 Process address space stack text data Address space Each process runs in its own virtual memory address space that consists of: Stack space – used for function and system calls Data space – variables (both initialized and uninitialized) Text – the program code (usually read only) Invoking the same program multiple times results in the creation of multiple distinct address spaces

49 49 Memory Program Code Program Data Running a process on a CPU CPU ALU ADD R1, R2 SPPC In its simplest form, a computer performs instructions on operands. Registers are used to hold values temporarily to speed things up

50 50 Switching among multiple processes Memory Program Code Program Data CPU ALU SPPC Program State Program 1 has CPU Saving all the information about a process allows a process to be temporarily suspended

51 51 Switching among multiple processes Memory Program Code Program Data CPU ALU SPPC Program State Program Code Program Data SUB R1, R2 Program 2 has CPU Saving all the information about a process allows a process to be temporarily suspended

52 52 Switching among multiple processes Memory Program Code Program Data CPU ALU SPPC Program State Program Code Program Data Program State Program 2 has CPU Saving all the information about a process allows a process to be temporarily suspended

53 53 Switching among multiple processes Memory Program Code Program Data CPU ALU SPPC Program State Program Code Program Data Program State Program 1 has CPU Saving all the information about a process allows a process to be temporarily suspended

54 54 Switching among multiple processes Memory Program Code Program Data CPU ALU SPPC Program State Program Code Program Data Program State ADD R1, R3 Program 1 has CPU Saving all the information about a process allows a process to be temporarily suspended

55 55 Why use the process abstraction? Multiprogramming of four programs in the same address space Conceptual model of 4 independent, sequential processes Only one program active at any instant

56 56 The role of the scheduler Lowest layer of process-structured OS handles interrupts & scheduling of processes Above that layer are sequential processes

57 57 Process states Possible process states running blocked ready

58 58 Implementation of process switching Skeleton of what the lowest levels of the OS do when an interrupt occurs

59 59 How do processes get created? Principal events that cause process creation System initialization Initiation of a batch job User request to create a new process Execution of a process creation system call from another process

60 60 Process hierarchies Parent creates a child process, special system calls for communicating with and waiting for child processes each process is assigned a unique identifying number or process ID (PID) Child processes can create their own child processes Forms a hierarchy UNIX calls this a "process group" Windows has no concept of process hierarchy all processes are created equal

61 61 How do processes terminate? Conditions which terminate processes Normal exit (voluntary) Error exit (voluntary) Fatal error (involuntary) Killed by another process (involuntary)

62 62 Process creation in UNIX All processes have a unique process id getpid(), getppid() allow processes to get their information Process creation fork() creates a copy of a process with the lone exception of the return value of fork() exec() replaces an address space with a new program system() like CreateProcess() Process termination, signaling signal(), kill() allows a process to be terminated or have specific signals sent to it

63 63 Example: process creation in UNIX … pid = fork() if (pid == 0) { // child… … exec(); } else { // parent wait(); } … csh (pid = 22)

64 64 Process creation in UNIX example … pid = fork() if (pid == 0) { // child… … exec(); } else { // parent wait(); } … csh (pid = 22) … pid = fork() if (pid == 0) { // child… … exec(); } else { // parent wait(); } … csh (pid = 24)

65 65 Process creation in UNIX example … pid = fork() if (pid == 0) { // child… … exec(); } else { // parent wait(); } … csh (pid = 22) … pid = fork() if (pid == 0) { // child… … exec(); } else { // parent wait(); } … csh (pid = 24)

66 66 Process creation in UNIX example … pid = fork() if (pid == 0) { // child… … exec(); } else { // parent wait(); } … csh (pid = 22) … pid = fork() if (pid == 0) { // child… … exec(); } else { // parent wait(); } … csh (pid = 24)

67 67 Process creation in UNIX example … pid = fork() if (pid == 0) { // child… … exec(); } else { // parent wait(); } … csh (pid = 22) //ls program main(){ //look up dir … } ls (pid = 24)

68 68 What other process state does the OS manage? Fields of a process table entry

69 69 What about the OS? Is the OS a process? It is a program in execution, after all … Does it need a process control block? Who manages its state when its not running?


Download ppt "1 OMSE 510: Computing Foundations 5: The Operating System Chris Gilmore Portland State University/OMSE."

Similar presentations


Ads by Google