Download Operating Systems: Principles and Practice, Introduction

Operating Systems
CSCI 411
Introduction
Content from
Operating Systems in Depth Thomas w. Doeppner ©2011
Operating Systems Principles & Practices by Anderson and Dahlin 2014
Tannenbaum 2015
M. Doman
Main Points (for today)
• Operating system definition
– Software to manage a computer’s resources for its
users and applications
• OS challenges
– Reliability, security, responsiveness, portability, …
• OS history
In the Beginning …
• There was hardware
–
–
–
–
–
processor
storage
card reader
tape drive
drum
• And not much else
– no operating system
– no libraries
– no compilers
IBM 650
OS:
none
get photo from: http://www03.ibm.com/ibm/history/exhibits/650/650_ph10.html]
Programming Without an OS
• Assemble all software into a deck of
punched cards
• Get 15-minute computer slot
1)
2)
3)
4)
pay $75 ($611 in 2010 dollars)
mount tapes containing data
read cards into computer
run program
– it probably crashes
5) output (possibly a dump) goes to printer
• Steps 1, 2, 3, and 5 take 10 minutes
– leaving 5 minutes for step 4!
Enter the OS …
• Group jobs into batches
• Setup done for all collectively
• Software doing this called Input/Output System
– the first operating system
Operating System Job
• Provide a user program with better, simpler,
cleaner, model of the computer
• Handle management of all computer
resources
Early Operating Systems:
Computers Very Expensive
• One application at a time
– Had complete control of hardware
– OS was runtime library
– Users would stand in line to use the computer
• Batch systems
– Keep CPU busy by having a queue of jobs
– OS would load next job while current one runs
– Users would submit jobs, and wait, and wait, and
Batch Systems (1)
Figure 1-3. An early batch system. (a) Programmers bring
cards to 1401. (b) 1401 reads batch of jobs onto tape.
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.
Batch Systems
Figure 1-4. Structure of a typical Fortran job.
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.
Time-Sharing Operating Systems:
Computers and People Expensive
• Multiple users on computer at same time
– Multiprogramming: run multiple programs at
same time
– Interactive performance: try to complete
everyone’s tasks quickly
– As computers became cheaper, more important to
optimize for user time, not computer time
Bonus Thought Question
• How should an operating system allocate
processing time between competing uses?
– Give the CPU to the first to arrive?
– To the one that needs the least resources to
complete? To the one that needs the most
resources?
– What if you need to allocate memory?
– Disk?
Today’s Operating Systems:
Computers Cheap
•
•
•
•
•
•
Smartphones
Embedded systems
Web servers
Laptops
Tablets
Virtual machines
Tomorrow’s Operating Systems
• Giant-scale data centers
• Increasing numbers of processors per
computer
• Increasing numbers of computers per user
• Very large scale storage
What is an operating system?
• Software to
manage a
computer’s
resources for
its users and
applications
Components of a Modern Computer
(2)
Figure 1-1. Where the operating system fits in.
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.
The Operating System as a Resource
Manager
• Top down view
– Provide abstractions to application programs
• Bottom up view
– Manage pieces of complex system
• Alternative view
– Provide orderly, controlled allocation of resources
Tanenbaum & Bo, Modern Operating
Systems:4th ed., (c) 2013 Prentice-Hall, Inc.
All rights reserved.
The Operating System as an Extended
Machine
Figure 1-2. Operating systems turn ugly hardware into
beautiful abstractions.
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.
Operating System Roles
• Referee:
– Resource allocation among users, applications
– Isolation of different users, applications from each other
– Communication between users, applications
• Illusionist
– Each application appears to have the entire machine to
itself
– Infinite number of processors, (near) infinite amount of
memory, reliable storage, reliable network transport
• Glue
– Libraries, user interface widgets, …
Thought Question
• What do you need from hardware to be able
to:
– Isolate different applications from each other?
– Isolate different users from accessing each others
files?
OS Challenges
• Reliability
– Does the system do what it was designed to do?
– Availability
• What portion of the time is the system working?
• Mean Time To Failure (MTTF), Mean Time to Repair
• Security
– Can the system be compromised by an attacker?
– Privacy
• Data is accessible only to authorized users
• Both require very careful design and code
OS Challenges
• Performance
– Latency/response time
• How long does an operation take to complete?
– Throughput
• How many operations can be done per unit of time?
– Overhead
• How much extra work is done by the OS?
– Fairness
• How equal is the performance received by different users?
– Predictability
• How consistent is the performance over time?
OS Challenges
• Portability
– For programs:
• Application programming
interface (API)
• Abstract machine interface
– For the operating system
• Hardware abstraction layer
• Hardware-specific OS
kernel routines
System Calls
• Sole interface between user and kernel
• Implemented as library routines that
execute trap instructions to enter kernel
• Errors indicated by returns of –1; error
code is in errno
if (write(fd, buffer, bufsize) == –1) {
// error!
printf("error %d\n", errno);
// see perror
}
Operating Systems
• Abstraction
– providing an “appropriate” interface for
applications
• Concerns
– performance
• time and space
–
–
–
–
sharing and resource management
failure tolerance
security
marketability
Abstractions
• Hardware
– disks
– memory
– processors
– network
– monitor
– keyboard
– mouse
• Operating system
– files
– programs
– threads of control
– communication
– windows, graphics
– input
– locator
Processes
• Fundamental abstraction of program execution
– memory
– processor(s)
• each processor abstraction is a thread
– “execution context”
Memory
Figure 1-8. (a) A quad-core chip with a shared L2 cache.
(b) A quad-core chip with separate L2 caches.
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.
Files
Memory
Disk
Disk
I/O Devices
Figure 1-11. (a) The steps in starting an I/O device
and getting an interrupt.
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.
Disks
Figure 1-10. Structure of a disk drive.
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.
Memory
Sharing (1)
Program 1
Program 2
Program 3
Operating
System
Memory
Scheduling Processes
Avoiding Deadlocks
Virtual Machines
Figure 1-29. (a) A type 1 hypervisor. (b) A pure type 2
hypervisor. (c) A practical type 2 hypervisor.
Tanenbaum & Bo, Modern Operating Systems:4th ed., (c) 2013 Prentice-Hall, Inc. All rights reserved.
The File Abstraction
• A file is a simple array of bytes
• Files are made larger by writing beyond their
current end
• Files are named by paths in a naming tree
• System calls on files are synchronous
Standard File Descriptors
main( ) {
char buf[BUFSIZE];
int n;
const char* note = "Write failed\n";
}
while ((n = read(0, buf, sizeof(buf))) > 0)
if (write(1, buf, n) != n) {
(void)write(2, note, strlen(note));
exit(EXIT_FAILURE);
}
return(EXIT_SUCCESS);