Understanding Operating Systems Sixth Edition - PowerPoint PPT Presentation

understanding operating systems sixth edition n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Understanding Operating Systems Sixth Edition PowerPoint Presentation
Download Presentation
Understanding Operating Systems Sixth Edition

play fullscreen
1 / 106
Understanding Operating Systems Sixth Edition
371 Views
Download Presentation
teenie
Download Presentation

Understanding Operating Systems Sixth Edition

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

  1. Understanding Operating SystemsSixth Edition Chapter 13 UNIX Operating System

  2. Learning Objectives After completing this chapter, you should be able to describe: • The goals of UNIX designers • The significance of using files to manipulate devices • The strengths and weaknesses of having competing versions of UNIX • The advantages of command-driven user interfaces • The roles of the Memory, Processor, Device, and File Managers in UNIX Understanding Operating Systems, Sixth Edition

  3. Overview • Unlike many OS, UNIX isn’t limited to specific computers using a particular microprocessor as a CPU. • There are many versions of UNIX and they run on all sizes of computers using a wide range of microprocessors. • Current versions of many other OS have been revised to include the capability to run UNIX applications and connect smoothly with UNIX networks. Understanding Operating Systems, Sixth Edition

  4. Overview (cont’d) • UNIX (authored by Ken Thompson) has three major advantages: • Portability • It is portable from large systems to small systems. • Its portability is attributed to the fact that most of it is written in a high-level language, C (authored by Dennis Ritchie), instead of assembly language. • Brief, single operation commands • Can be combined in a single command line to achieve any desired goal. • A feature that many programmer find endearing. • Application device independence • It can be configured to operate virtually any type of device. Understanding Operating Systems, Sixth Edition

  5. History • The evolution of UNIX (Table 13.1) starts with a research project that began in 1965 as a joint venture between Bell Labs, AT&T, General Electric, and MIT. • When Bell Labs withdrew from the project in 1969, AT&T management decided not to undertake the development of any more OS. • KenThompson and Dennis Ritchie kept at it. • Some people say they needed a new OS to support their favorite computer game. • Regardless of their reasons for developing it, UNIX grew to become one of the most widely used OS in history. Understanding Operating Systems, Sixth Edition

  6. History (cont'd.) Understanding Operating Systems, Sixth Edition

  7. History (cont'd.) Understanding Operating Systems, Sixth Edition

  8. The Evolution of UNIX • Thompson and Ritchie originally wrote UNIX in assembly language for a Digital Equipment Corporation PDP-7 computer. • It was named “UNIX” by Brian Kernighan as a play on words from MULTICS. • The first official version, presented in 1971 by Thompson and Ritchie, was designed to “do one thing well” and run on a popular DEC minicomputer. • Before long, UNIX became known as a formidable OS. Understanding Operating Systems, Sixth Edition

  9. The Evolution of UNIX (cont'd.) • For Version 3, Ritchie developed a new programming language, C, and wrote a compiler for the C language, which made it easier and faster for system designers to write code. • As UNIX grew in fame and popularity, AT&T found itself in a difficult situation. • It was forbidden by U. S. federal government antitrust regulations to sell software. • But it could, for a nominal fee, make the OS available first to universities and later to independent developers who, in turn, transformed it into a commercial product. Understanding Operating Systems, Sixth Edition

  10. The Evolution of UNIX (cont'd.) • Between 1973 and 1975, several improved versions were developed. • The most popular version was developed at the University of California at Berkley. • It became known as BSD. • Its popularity in universities created a demand for it in business and industry. • AT&T tried to promote its version of UNIX as the standard version, but UNIX had already been adopted and adapted by too many designers for too many computers. Understanding Operating Systems, Sixth Edition

  11. The Evolution of UNIX (cont'd.) • By 1990 there were about two dozen versions of UNIX. • In 1991, IBM and Hewlett-Packard were among the companies that established “The Open Group”. • Owns the trademark to the name UNIX, and created a standard version of the OS. • By 1993 Berkeley released 4.4 bsd based on AT&T’s UNIX, requiring customers to obtain licenses from AT&T to use it. • Shortly thereafter, Novell acquired UNIX from AT&T and released its own version called UnixWare to interact with Novell’s NetWare system. Understanding Operating Systems, Sixth Edition

  12. The Evolution of UNIX (cont'd.) • The original “do one thing well” position of the early commands has been modified in current releases and recent commands offer many options and controls. • Although some commands may be more difficult to use, they can be adapted to new situations with relative ease. • The key features of the early systems have been preserved, while the potential of the commands has increased to meet new needs. Understanding Operating Systems, Sixth Edition

  13. The Evolution of UNIX (cont'd.) • UNIX offers full support for local area networks and complies with international standards. • System security has been greatly improved and meets many of the U.S. government security requirements. • Most UNIX systems feature a GUI designed to give UNIX systems a standard look. • To resolve the issue of multiple standards, the industry continues to try to standardize to improve portability of programs from one system to another. • The release of ISO/IEC 9945:2003 was a big step in that direction. Understanding Operating Systems, Sixth Edition

  14. Design Goals • From the beginning, Thompson and Ritchie envisioned UNIX as an operating system created by programmers for programmers. • It was to be fast, flexible, and easy to use. • The immediate goals were twofold: • To develop an OS that would support software development. • Included utilities in the OS for which programmers at the time needed to write customized code. • Each utility was designed for simplicity: do one thing well. • These utilities were designed to be used in combination with each other so that programmers could select and combine any appropriate utilities that might be needed to carry out specific jobs. Understanding Operating Systems, Sixth Edition

  15. Design Goals (cont’d) • The immediate goals were twofold (cont’d): • To keep the OS simple. • Thompson and Ritchie selected the algorithms based on simplicity instead of speed and sophistication. • As a result, UNIX can be mastered by experienced programmers in a matter of weeks. Understanding Operating Systems, Sixth Edition

  16. Design Goals (cont'd.) • The designers’ long-term goal was to make the OS, and any application software developed for it, portable from one computer to another. • The obvious advantage of portability is that it: • Reduces conversion costs • Doesn’t cause application packages to become obsolete with every change in hardware. • This goal was finally achieved with UNIX version 4 because it was device independent – an innovation at the time. Understanding Operating Systems, Sixth Edition

  17. Design Goals (cont'd.) • Numerous versions of UNIX meet the design element of conforming to the specifications for Portable Operating System Interface for Computer Environments (POSIX) • A registered trademark of the IEEE. • POSIX is a family of IEEE standards that define a portable operating system interface to enhance the portability of programs from one operating system to another. • IEEE STD. 1003.1 (2004 edition) Understanding Operating Systems, Sixth Edition

  18. Memory Management • For multiprogramming systems, most UNIX OS use either swapping or demand paging (or both) memory management techniques. • The best choice depends on the kind of applications that will run on the system. • If most jobs are small then swapping could be the best choice. • If the system will be running many large jobs then demand paging is best. Understanding Operating Systems, Sixth Edition

  19. Memory Management (cont’d) • Swapping (small jobs) • Requires that the entire program in main memory before it can be executed. • This poses a size restriction on programs. • Uses a round robin policy • When a job’s time slice is up, or when it generates an I/O interrupt, the entire job is swapped out to secondary storage to make room for other jobs waiting in the READY queue. • When traffic is heavy this swapping back and forth can slow down the system. Understanding Operating Systems, Sixth Edition

  20. Memory Management (cont’d) • Demand paging (large jobs) • Requires more complicated hardware configurations; • Increases the system overhead • Might lead to Thrashing (under heavy loads). • Has the advantage of implementing the concept of virtual memory. Understanding Operating Systems, Sixth Edition

  21. Memory Management (cont'd.) • Typical internal memory layout (single user) • Program code • Data segment • Stack Understanding Operating Systems, Sixth Edition

  22. Memory Management (cont'd.) • Program code • In Figure 13.2, the segment called program code is the sharable portion of the program. • Because this code can be physically shared by several processes, it must be written in reentrant code. • The code is protected so that its instructions aren’t modified in any way during its normal execution. • All data references are made without the use of absolute physical addresses. Understanding Operating Systems, Sixth Edition

  23. Memory Management (cont'd.) • Program code (cont’d) • The Memory Manager gives the program code special treatment. • Because several programs will be sharing it, the space allocated to the program can’t be released until all of the processes using it have completed their execution. • UNIX uses a text table to keep track of which processes are using which program code. • The memory isn’t released until the program code is no longer needed. • The data segment (Figure 3.2) starts after the program code and grows toward higher memory locations as needed by the program. Understanding Operating Systems, Sixth Edition

  24. Memory Management (cont'd.) • The stack segment starts at the highest memory locations and grows downward as subroutine calls and interruptsadd information to it. • A stack is a section of main memory where process information is saved when a program is interrupted, or for temporary storage. • The data and stack are nonsharable sections of memory, so when the original program terminates the memory, space is released. Understanding Operating Systems, Sixth Edition 24

  25. Memory Management (cont'd.) • The UNIX kernel, which permanently resides in memory, is the part of the OS that implements the “system calls” to set up the memory boundaries so several processes can coexist in memory at the same time. • The processes also use system calls to interact with the File Manager and to request I/O services. • The kernel is the set of programs that implements the most primitive of that system’s functions. • The only part of the OS to permanently reside in memory. Understanding Operating Systems, Sixth Edition

  26. Memory Management (cont'd.) • The UNIX kernel (cont’d) • The remaining sections of the OS are handled in the same manner as any large program. • The pages of the OS are brought into memory on demand, only when they’re needed, and their memory space is released as other pages are called. • UNIX uses the least recently used (LRU) page replacement algorithm. • UNIX uses the same memory management concepts for networked computers, single-user systems, and multi-user systems. Understanding Operating Systems, Sixth Edition

  27. Memory Management (cont'd.) • The UNIX kernel (cont’d) • With the 64-bit addressing architecture in modern UNIX versions, the Mac OS X, the OS can make much faster system calls, which, in turn, improves the performance of I/O applications and network response. • The 64-bit addressing scheme is one shared by most OS. Understanding Operating Systems, Sixth Edition

  28. Process Management • The Processor Manager of a UNIX system handles: • The allocation of the CPU; • Process scheduling; • The satisfaction of process requests. • To perform these tasks, the kernel maintains several important tables to coordinate the execution of processes and the allocation of devices. • Using a predefined policy, the Process Scheduler selects a process from the READY queue and begins its execution for a given time slice. Understanding Operating Systems, Sixth Edition

  29. Process Management (cont'd.) • The process scheduling algorithm picks the process with the highest priority to runfirst. • Since one of the values used to compute the priority is accumulated CPU time, any processes that have used a lot of CPU time will get a lower priority than those that have not. • The system updates the Compute-to-total-time ratio for each job everysecond. • This ratio divides the amount of CPU time that a process has used up by the total time the same process has spent in the system. • A result close to 1 would indicate that the process is CPU-bound. Understanding Operating Systems, Sixth Edition

  30. Process Management (cont'd.) • Process scheduling algorithm (cont'd.) • If several processes have the same computed priority, they’re handled round robin. • Low-priority processes are preempted by high-priority processes. • Interactive processes typically have a low computer-to-total-time ratio, so interactive response is maintained without any special policies. • The overall effect of this negative feedback is that the system balances I/O-bound jobs with CPU-bound jobs to keep the processor busy and to minimize the overhead for waiting processes. Understanding Operating Systems, Sixth Edition

  31. Process Management (cont'd.) • Process scheduling algorithm (cont'd.) • When the Processor Manager is deciding which process from the READY queue will be loaded into memory to be run first, it chooses the process with the longest time spent on the secondary storage. • When the Processor Manager is deciding which process (currently in memory and waiting or ready to be run) will be moved out temporarily to make room for a new arrival, it chooses the process that’s either waiting for disk I/O or that’s currently idle. • If there are several processes to choose from, the one that has been in memory the longest is moved out first. Understanding Operating Systems, Sixth Edition

  32. Process Management (cont'd.) • Process scheduling algorithm (cont'd.) • If a process is waiting for the completion of an I/O request and isn’t ready to run when it’s selected, UNIX will dynamically recalculate all process priorities to determine which inactive but READY process will begin execution when the processor becomes available. • If a disk is used for secondary file storage as well as a “swapping area”, then heavy traffic can significantly slow disk I/O because job swapping may take precedence over file storage. Understanding Operating Systems, Sixth Edition

  33. Process Table Versus User Table • UNIX uses several tables to keep the system running smoothly. • Information on simple processes, those with nonsharable code, is stored in: • The Process Table • Always resides in memory • The User Table • Resides in memory only while the process is active. • User table, process data segment, code segment • Swapped as needed Understanding Operating Systems, Sixth Edition

  34. Process Table Versus User Table (cont'd.) • Process table • Each entry contains: • Process identificationnumber; • User identification number; • Process memory address or secondary storageaddress; • Process size and scheduling information. • This table is set up when the process is created and is deleted when the process terminates. Understanding Operating Systems, Sixth Edition

  35. Process Table Versus User Table (cont'd.) • Text table • For processes with sharable code, the Process Table maintains a subtable called the Text Table which contains: • Memory address or secondarystorage address of text segment (sharable code); • A count to keep track of the number of processes using this code; • Every time a process starts using this code, the count is increased by 1; • Every time a process stops using this code, the count is decreased by 1; • When the Count is equal to 0, the code is no longer needed and the table entry is released together with any memory locations that have been allocated to the code segment. Understanding Operating Systems, Sixth Edition

  36. Process Table Versus User Table (cont'd.) • User table • Allocated to each active process. • Kept in the transient memory area of memory as long as the process is active. • Contains: • The user and group identification numbers to determine file access privileges; • Pointers to the system’s file table for every file being used by the process. • A Pointer to the current directory; • A list of responses for various interrupts. • This table, together with the process data segment and its code segment, can be swapped into or out of main memory as needed. Understanding Operating Systems, Sixth Edition

  37. Synchronization • UNIX is a true multitasking OS. • It achieves process synchronization by requiring that processes wait for certain events. • If a process needs more memory, it’s required to wait for an event associated with memory allocation. • When memory becomes available, the event is signaled and the process can continue. • Each event is represented by integers that are equal to the address of the table associated with the event. Understanding Operating Systems, Sixth Edition

  38. Synchronization (cont'd.) • fork • An unusual feature of UNIX is that it gives the user the capability of executing oneprogram from another program using the fork command. • This command gives the second program all the attributes of the first program, such as any open files, and saves the first program in its original form. • The system call fork splits a program into two copies, which are both running from the statement after the fork command. • When fork is executed, a “process id” (PID) is generated for the new process. • This is done in a way that ensures that each process has its own unique ID number. Understanding Operating Systems, Sixth Edition

  39. Synchronization (cont'd.) • Fork (cont’d) • Figure 13.4 shows what happens after the fork. • The original process (Process 1) is called the parent process and the resulting process (Process 2) is the child process. • A child inherits the parent’s open files and runs asynchronously with it unless the parent has been instructed to wait for the termination of the child process. Understanding Operating Systems, Sixth Edition

  40. Synchronization (cont'd.) Understanding Operating Systems, Sixth Edition

  41. Synchronization (cont'd.) • wait • A related command, wait, allows the programmer to synchronize process execution by suspending the parent until the child is finished (Figure 13.5). • In Figure 13.5, the IF-THEN-ELSE structure is controlled by the value assigned to the pid, which is returned by the fork system call. • A pid > zero indicates a parent process. • A pid = zero indicates a child process. • A pid < zero (negative) indicates an error in the fork call. Understanding Operating Systems, Sixth Edition

  42. Synchronization (cont'd.) Understanding Operating Systems, Sixth Edition

  43. Synchronization (cont'd.) • exec • The exec family of cammands is used to start execution of a new program from another program. • execl, execv, execls, execlp, and execvp • Unlike fork, which results in two processes running the same program being in memory, a successful exec call will: • Overlay the second program over the first; • Leaving only the second program in memory. • The second program’s code and data are now part of the original process whose pid does not change. Understanding Operating Systems, Sixth Edition

  44. Synchronization (cont'd.) • Exec (cont’d) • There’s no return from a successful exec call. • Therefore, the concept of parent-child doesn’t hold here. • ond program’s code and data are now part of the original process whose pid does not change. Understanding Operating Systems, Sixth Edition

  45. Synchronization (cont'd.) Understanding Operating Systems, Sixth Edition

  46. Device Management • UNIX is designed to provide device independence to the applications running under it. • This is achieved by treating each I/O device as a special type of file. • Every device installed in a UNIX system is assigned a name that’s similar to the name given to any other file, which is given descriptors called “iodes”. • These descriptors identify the devices, contains device information, and are stored in the device directory. • The subroutines that work with the OS to supervise the transmission of data between main memory and a peripheral unit are called device drivers. Understanding Operating Systems, Sixth Edition

  47. Device Management (cont'd.) • The actual incorporation of a device driver into the kernel is done during the systemconfiguration. • UNIX has a program called config that will automatically create a conf.c file for any given hardware configuration. • This conf.c file contains the parameters that control resources such as: • The number of internal buffers for the kernel: • The size of the swap space. • In addition, the conf.c file contains twotables: • bdevsw (“block device switch”) • cdevsw (“character device switch”) Understanding Operating Systems, Sixth Edition

  48. Device Management (cont'd.) • These two tables provide the UNIX system kernel with the ability to adapt easily to different hardware configurations by installing different driver modules. Understanding Operating Systems, Sixth Edition

  49. Device Classifications • The I/O system is divided into : • The “Block I/O” system (“structured I/O” system) • The “Character I/O” system (“unstructured I/O” system) • Each physical device is identified by (Figure 13.7): • A minor device number; • A major device number; • A class: • Block • Character Understanding Operating Systems, Sixth Edition

  50. Device Classifications (cont'd.) Understanding Operating Systems, Sixth Edition