1 / 27

Lecture 12

Lecture 12. Operating Systems (S&G, §6.4). Read S&G ch. 7, §§7.1 – 7.8 (High-Level Languages) for next week. Operating Systems. Wait for user requests Launch programs (e.g., assemblers, loaders) to service those requests Provide many other services to the user…. (slide < C. Hundhausen).

careyl
Télécharger la présentation

Lecture 12

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. Lecture 12 Operating Systems (S&G, §6.4) CS 100 - Lecture 12

  2. Read S&G ch. 7,§§7.1 – 7.8(High-Level Languages)for next week CS 100 - Lecture 12

  3. Operating Systems • Wait for user requests • Launch programs (e.g., assemblers, loaders) to service those requests • Provide many other services to the user… CS 100 - Lecture 12 (slide < C. Hundhausen)

  4. User Interface • Operating system’s most important task: Wait for user requests and process them • Receptionist • Dispatcher • The user interface performs this task CS 100 - Lecture 12 (slide adapted < C. Hundhausen)

  5. Text-OrientedUser Interface Traditional user interface:command line • e.g., DOS, Linux, UNIX • > cd mydocs/history • > ls • > ls –al > out.txt • > grep "http" *.html | more CS 100 - Lecture 12 (slide adapt. < C. Hundhausen)

  6. GraphicalUser Interface(GUI) Modern alternative: Graphical User Interface • Pioneered by Apple Macintosh (1984) • Windows, Icons, Menus, Pointer (WIMP) • Directories represented by folder icons • Files represented by specialized icons CS 100 - Lecture 12 (slide adapt. < C. Hundhausen)

  7. Security • In the 50s and 60s, physical security restricted access to computers and the files and programs they stored • In modern times, that responsibility has shifted to the operating system • Operating system controls access to computer by requiring users to log in with a username and password CS 100 - Lecture 12 (slide < C. Hundhausen)

  8. Encrypted Passwords • OS encrypts passwords so that they can’t be stolen • Encryption an active research area in computer science • Need both encrypted text and algorithm for decoding it • Modern “public key” cryptography based on extremely large prime numbers CS 100 - Lecture 12 (slide < C. Hundhausen)

  9. File Access Permissions • OS restricts users from accessing the files of others • Files can be set so that they are readable, writable, and executable by only a limited set of people, e.g.: • Only the owner • Only users in the owner’s group • Anyone • Authorization lists maintain this information; they are encrypted so that they cannot be modified by unauthorized users • OS prevents you from harming yourself CS 100 - Lecture 12 (slide adapt. < C. Hundhausen)

  10. Hierarchy of File Access Permissions Delete • Change • Append • Read CS 100 - Lecture 12

  11. Process Scheduling • Operating system ensures that the processor is being utilized efficiently • While waiting for I/O operations to complete, the computer can do useful work • This is done by maintaining a queue of processes (programs) to be run • Programs have three status levels • Running • Ready • Waiting CS 100 - Lecture 12 (slide < C. Hundhausen)

  12. D reads a disk file A waits for keyboard input B writes to the printer; keystroke arrives for A Process Scheduling (2) waiting ready running event A, B, C D D B, C A A, D C B B, D C A Etc…. CS 100 - Lecture 12 (slide adapt. < UT Austin)

  13. Deadlock • Operating system aims to prevent deadlock: a state in which no useful work can be done • How deadlock happens (example) • Programs A and B both want to print a file located on the CD-ROM • A requests CD-ROM, then printer • B requests printer, then CD-ROM • A obtains CD-ROM, but is told that printer is not available • B obtains printer, but is told that CD-ROM is not available • Deadlock! • Both are waiting for a resource allocated to the other • the only way to end the wait is for one of them to free the resource that the other needs CS 100 - Lecture 12 (slide < C. Hundhausen)

  14. Deadlock Prevention • How to prevent deadlock • If all resources needed by a program are available • allocate the resources to the program • If not all resources needed by a program are available • do not allocate any resources to the program • require the program to make a new request for resources • This algorithm would prevent deadlock in the preceding example: • A and B both want to print a file located on CD-ROM • A requests CD-ROM and printer • A obtains CD-ROM and printer • B requests printer and CD-ROM. The request is denied • A finishes and releases CD-ROM and printer • B re-requests printer and CD-ROM • B obtains printer and CD-ROM • Deadlock is prevented! CS 100 - Lecture 12 (slide adapt. < C. Hundhausen)

  15. First Generation (1945–55) • No operating systems • Assemblers and loaders only • Programmers themselves managed allocation of resources and execution of programs • They signed up for blocks of time • They brought in their punched card programs during their allocated block of time • They manually loaded punched cards into computers • They pressed buttons on console to initiate assembler translation process • They manually loaded computer program into memory and began its execution • This was a very tedious process! CS 100 - Lecture 12 (slide adapt. < C. Hundhausen)

  16. Second Generation (1955–65) • 1st generation systems often sat idle, because programmers spent a lot of their allocated time thinking and troubleshooting • Led to development of batch operating systems • Computer programmers hand in programs to computer operator, who runs collections of programs in batches CS 100 - Lecture 12 (slide adapt. < C. Hundhausen)

  17. Second Generation (2) • Command languages introduced • Enable programmers to specify to operating system what they want done • Usually a mix of programs, data, and commands • Role of operating systems as “receptionist” and “dispatcher” was born CS 100 - Lecture 12 (slide adapt. < C. Hundhausen)

  18. Third Generation (1965-1985) • As computational speeds improved, it became unacceptable for computers to sit and wait for I/O operations • The goal: Minimize CPU idle time • Multiprogramming operating systems were born • Many user programs loaded simultaneously into memory • If program has to pause for I/O, another program begins executing • Substantial improvements in CPU utilization were realized CS 100 - Lecture 12 (slide adapt. < C. Hundhausen)

  19. Third Generation (2) • Issue: With multiple programs in memory, programs run risk of corrupting other programs by writing in their memory space • Solution: • Keep track of beginning and ending address of each program’s memory space • If a program attempts to reference/write to memory outside of its boundaries: • report an error message • shut down the program • resume execution of another program CS 100 - Lecture 12 (slide adapt. < C. Hundhausen)

  20. Third Generation (3) • Time sharing systems emerged • Took advantage of emerging network technologies • Like multi-programming OS • But programs do not have to be loaded into memory in advance • Rather, programs can be loaded dynamically by users sitting at remote terminals; illusion of single-user computer • Need for computer security emerged, because computer could now be accessed remotely • Since many users accessed the computer simultaneously, I/O events could no longer be the only event that triggered a switch to a new program • A given program is run for a designated time slice • When time slice is up or an I/O operation occurs, the CPU begins running another program • This proceeds in round-robin fashion CS 100 - Lecture 12 (slide < C. Hundhausen)

  21. Fourth Generation (1985-present) • Personal computers became cheap and powerful enough that they could get work done more efficiently than a timeshare system • At the same time, computer peripherals remained expensive • This suggested that local computation was desirable, with remote access to more expensive peripherals • Return to single-user computer but with much better OS CS 100 - Lecture 12 (slide < C. Hundhausen)

  22. Fourth Generation (2) • Network operating systems emerged • Manages resources of local computer (client) • Manages shared resources (servers) of a local area network (LAN) • Typical servers include file, mail, and print CS 100 - Lecture 12 (slide adapt. < C. Hundhausen)

  23. Fourth Generation (3) Real-time operating systems • Manage resources of embedded systems that are placed inside equipment (e.g., automobiles, airplanes, ovens, watches) • Prioritizes requests, so that most critical ones are serviced first • E.g., request for collision avoidance in an airplane would be serviced before request to turn up the heat in the cabin CS 100 - Lecture 12 (slide < C. Hundhausen)

  24. Future Generations • Multimedia, multimodal, and tangible user interfaces (speech, gesture, virtual reality, etc.) • Issue commands via speech, gesture, interaction with tangible objects • Parallel processing • Distributed operating systems • No boundaries between local area networks and global networks • Users no longer need to be aware of where a resource is coming from • Users can utilize global resources seamlessly – as though they are local resources • But, physical location is not irrelevant CS 100 - Lecture 12 (slide < C. Hundhausen)

  25. Ad Hoc Networks • Wireless & mobile communication • No fixed network structure (pattern of interconnectivity) • Each node discovers & keeps track of which other nodes it can communicate with • Messages are routed in accordance with current configuration of nodes • Self-organize & adapt like social networks CS 100 - Lecture 12

  26. “Smart Dust” • Currently available “motes”: • Bottle-cap size • $100–$200 each ($1 in 5 years) • Sense temperature, light, motion, energy use, GPS, gas, pressure, … • Set up ad hoc network • Battery lasts for years • 8K program memory, 512K RAM • coded in C, runs TinyOS • See Dust Inc. <http://www.dust-inc.com> • Privacy issues? CS 100 - Lecture 12

  27. CS 100 - Lecture 12 (fig. < IEEE Computer)

More Related