Lecture 12
2/19/04 13:42
Read S&G ch. 7,
§§7.1
§§7.1 – 7.8
(High-Level Languages)
for next week
Lecture 12
Operating Systems
(S&G, §6.4)
2/19/04
CS 100 - Lecture 12
1
Operating Systems
2/19/04
CS 100 - Lecture 12
2
User Interface
• Wait for user requests
• Launch programs (e.g., assemblers, loaders)
to service those requests
• Provide many other services to the user…
• Operating system’s
most important task:
Wait for user requests
and process them
– Receptionist
– Dispatcher
• The user interface
performs this task
2/19/04
CS 100 - Lecture 12
3
2/19/04
CS 100 - Lecture 12
4
(slide adapted < C. Hundhausen)
(slide < C. Hundhausen)
Text-Oriented
User Interface
Graphical
User Interface
(GUI)
Traditional user interface:
command line





2/19/04
CS 100 - Lecture 12
(slide adapt. < C. Hundhausen)
CS 100
Modern alternative: Graphical User Interface
e.g., DOS, Linux, UNIX
> cd mydocs/history
> ls
> ls –al > out.txt
> grep "http" *.html | more




5
2/19/04
Pioneered by Apple Macintosh (1984)
Windows, Icons, Menus, Pointer (WIMP)
Directories represented by folder icons
Files represented by specialized icons
CS 100 - Lecture 12
6
(slide adapt. < C. Hundhausen)
1
Lecture 12
2/19/04 13:42
Security
Encrypted Passwords
• 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
• OS encrypts passwords so that they can’t be
stolen
2/19/04
CS 100 - Lecture 12
– 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
7
2/19/04
CS 100 - Lecture 12
8
(slide < C. Hundhausen)
(slide < C. Hundhausen)
File Access Permissions
Hierarchy of File Access
Permissions
• OS restricts users from accessing the files of
others
Delete
– Files can be set so that they are readable, writable, and
executable by only a limited set of people, e.g.:
Change
• Only the owner
• Only users in the owner’s group
• Anyone
Append
Read
– Authorization lists maintain this information; they are
encrypted so that they cannot be modified by
unauthorized users
• OS prevents you from harming yourself
2/19/04
CS 100 - Lecture 12
9
2/19/04
CS 100 - Lecture 12
10
(slide adapt. < C. Hundhausen)
Process Scheduling (2)
Process Scheduling
• Operating system ensures that the processor is
being utilized efficiently
waiting
– While waiting for I/O operations to complete, the
computer can do useful work
• Running
• Ready
• Waiting
B, C
A
A, D
C
B
B, D
C
A
event
D reads a disk file
B writes to the printer;
keystroke arrives for A
Etc….
CS 100 - Lecture 12
(slide < C. Hundhausen)
CS 100
D
A waits for keyboard input
– Programs have three status levels
2/19/04
running
A, B, C
D
• This is done by maintaining a queue of processes
(programs) to be run
ready
11
2/19/04
CS 100 - Lecture 12
12
(slide adapt. < UT Austin)
2
Lecture 12
2/19/04 13:42
Deadlock
•
•
Deadlock Prevention
•
Operating system aims to prevent deadlock: a state in
which no useful work can be done
How deadlock happens (example)
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
– Programs A and B both want to print a file located on the CDROM
– 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!
•
This algorithm would prevent deadlock in the preceding
example:
–
–
–
–
–
–
–
–
• 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
2/19/04
CS 100 - Lecture 12
13
2/19/04
(slide < C. Hundhausen)
CS 100 - Lecture 12
Second
Generation
(1955–65)
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!
2/19/04
CS 100 - Lecture 12
15
2/19/04
(slide adapt. < C. Hundhausen)
Second
Generation (2)
•
•
2/19/04
CS 100 - Lecture 12
(slide adapt. < C. Hundhausen)
CS 100
14
(slide adapt. < C. Hundhausen)
First Generation (1945–55)
•
•
•
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!
•
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
16
(slide adapt. < C. Hundhausen)
Command languages
introduced
Third Generation (1965-1985)
– Enable programmers
to specify to
operating system
what they want done
– Usually a mix of
programs, data, and
commands
• 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
Role of operating
systems as
“receptionist” and
“dispatcher” was
born
17
– 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
2/19/04
CS 100 - Lecture 12
18
(slide adapt. < C. Hundhausen)
3
Lecture 12
2/19/04 13:42
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:
CS 100 - Lecture 12
•
19
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
•
• report an error message
• shut down the program
• resume execution of another
program
2/19/04
Third Generation (3)
•
•
•
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
2/19/04
(slide adapt. < C. Hundhausen)
• 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
• 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
20
Fourth Generation (2)
Fourth Generation (1985-present)
2/19/04
CS 100 - Lecture 12
(slide < C. Hundhausen)
21
2/19/04
(slide < C. Hundhausen)
CS 100 - Lecture 12
22
(slide adapt. < C. Hundhausen)
Future Generations
Fourth Generation (3)
• Multimedia, multimodal, and tangible user
interfaces (speech, gesture, virtual reality, etc.)
– Issue commands via speech, gesture, interaction with
tangible objects
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
• 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
– E.g., request for collision avoidance in an airplane
would be serviced before request to turn up the heat in
the cabin
2/19/04
CS 100 - Lecture 12
(slide < C. Hundhausen)
CS 100
23
2/19/04
CS 100 - Lecture 12
24
(slide < C. Hundhausen)
4
Lecture 12
2/19/04 13:42
“Smart Dust”
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
2/19/04
2/19/04
CS 100 - Lecture 12
25
CS 100 - Lecture 12
27
• Currently available “motes”:
– Bottle-cap size
– $100–$200 each
– Sense temperature, light, motion, energy use, GOS, 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?
2/19/04
CS 100 - Lecture 12
26
(fig. < IEEE Computer)
CS 100
5