1 OS Lecture

Dr Anil Kumar
 Hardware
◦ Provides basic computing resources (CPU, memory,
I/O devices).
 Operating System
◦ Controls and coordinates the use of hardware among
application programs.
 Application Programs
◦ Solve computing problems of users (compilers,
database systems, video
◦ games, business programs such as banking software).
 Users
◦ • People, machines, other computers
 OS is the software that acts an intermediary (agent or
mediator) between the user applications and
computer hardware.
 Function of OS
◦ Memory Management System
◦ File Management System
◦ Resource Management System
◦ Process Management System
◦ Protection and Security
 Protection mechanisms control access of programs and
processes to user and system resources.
◦ Protect user from himself, user from other users,
system from users.
 Protection mechanisms must:
◦ Distinguish between authorized and unauthorized
use.
◦ Specify access controls to be imposed on use.
◦ Provide mechanisms for enforcement of access
control.
 • Security mechanisms provide trust in system and
privacy
◦ authentication, certification, encryption etc.
 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
 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?
 Portability
◦ For programs:
◦ Application programming interface (API)
◦ For the kernel
◦ Hardware abstraction layer
 Need to understand interaction between the
hardware and software
◦ Need to understand basic principles in the
design of computer systems efficient
resource management, security, flexibility
 Because it enables you to do things that are
difficult/impossible otherwise.
 Early Operating Systems
 Simple Batch Systems
 Multi-programmed Batch Systems
 Time-sharing Systems
 Personal and mobile Computer Systems
Structure
• Large machines run from console
• Single user system
• Programmer/User as operator
• Paper tape or punched cards
Early software
• Assemblers, compilers, linkers,
loaders,
device drivers, libraries of common
subroutines.
Secure execution
• Inefficient use of expensive
resources
• Low CPU utilization, high setup
time. Hardware – expensive ; Human –
cheap
 Reduce setup time by batching jobs with similar requirements.
 Hire an operator
◦ User is NOT the operator
 Automatic job sequencing
◦ Forms a rudimentary OS.
◦ Resident Monitor
 Holds initial control, control transfers to job and then back to monitor.
 Problem
◦ Need to distinguish job from job and data from program.
◦ Special cards indicate what to do.
◦ User program prevented from performing I/O
Solutions to speed up I/O:
 • Offline Processing
◦ load jobs into memory from tapes, card reading
and line printing are done
 offline.
◦ User submits card deck
◦ cards put on tape
◦ tape processed by operator
◦ output written to tape
◦ tape printed on printer
◦ Separate user from computer
 • Problems
◦ Long turnaround time - up to 2 DAYS!!!
◦ Low CPU utilization
◦ I/O and CPU could not overlap; slow mechanical devices
 Spooling (Simultaneous Peripheral Operation On-Line)
◦ Use disk (random access device) as large storage for reading
as many input files as possible and storing output files until
output devices are ready to accept them.
 Allows overlap - I/O of one job with computation of another.
 Introduces notion (idea or concept) of a job pool that allows
choose next job to run so as to increase CPU utilization
 Data moved directly between I/O devices and memory
 CPU can work on other tasks
How do we know that I/O is complete?
 Polling:
◦ Device sets a flag when it is busy.
◦ Program tests the flag in a loop waiting for completion of
I/O.
 Interrupts:
◦ On completion of I/O, device forces CPU to jump to a
specific
 instruction address that contains the interrupt service routine.
◦ After the interrupt has been processed, CPU returns to code
it was executing prior to servicing the interrupt.
 Use interrupts to run multiple programs
simultaneously
◦ When a program performs I/O, instead of polling,
execute another program till interrupt is received.
 Requires secure memory, I/O for each program.
 Requires intervention if program indefinite loops.
 Requires CPU scheduling to choose the next job to
run.
Hardware – getting cheaper; Human – getting expensive
 •Programs queued for execution in FIFO order.
 •Like multiprogramming, but timer device interrupts after a quantum (time slice).
◦ Interrupted program is returned to end of FIFO
◦ Next program is taken from head of FIFO
 Control card interpreter replaced by command language interpreter.
 Interactive (action/response)
◦ when OS finishes execution of one command, it seeks the next
control statement from user.
 File systems
◦ online files system is required for users to access data and code.
 Virtual memory
◦ Job is swapped in and out of memory to disk.
Hardware – cheap ; Human – expensive
•Single user systems, portable.

•I/O devices - keyboards, mice, display screens, small printers.
•Single user systems may not need advanced CPU utilization or protection
features.
•Advantages:
user convenience, responsiveness, ubiquitous
•Single user, multiple computers

•Laptops
•Smart phones
•Tablets
•Smart glasses
•Smart watches
 I/O devices and the CPU execute concurrently.
◦ Each device controller is in charge of a particular
device type
◦ Each device controller has a local buffer. I/O is
from the device to local buffer of controller
 CPU moves data from/to main memory to/from the
local buffers
 Device controller interrupts CPU on completion of
I/O
 Interrupt transfers control to the interrupt service
routine
◦ Interrupt Service Routine: Segments of code that
determine action to be taken for interrupt.
 Determining the type of interrupt
◦ Polling: same interrupt handler called for all
interrupts, which then polls all devices to figure out
the reason for the interrupt
◦ Interrupt Vector Table: different interrupt handlers
will be executed for different interrupts
 OS preserves the state of the CPU
◦ stores registers and the program counter
(address of interrupted instruction).
 Incoming interrupts are disabled while another
interrupt is being processed to prevent a lost
interrupt.
 Synchronous I/O
◦ After I/O is requested, wait until I/O is done.
Program will be idle.
◦ no simultaneous I/O processing, at most one
outstanding I/O request at a time.
 Asynchronous I/O
◦ After I/O is requested, control returns to user
program without waiting for I/O completion.
•Used for high speed I/O devices able to transmit information at close to
memory speeds.
• Device controller transfers blocks of data from buffer storage directly to main
memory without CPU intervention.
 Process: an instance of a program, running with
limited rights
 Thread: a sequence of instructions within a process
 Potentially many threads per process (for now
1:1)
 Address space: set of rights of a process
◦ Memory that the process can access
◦ Other permissions the process has (e.g., which
system calls it can make, what files it can access)
 Most modern OS include the notion (idea/view) of a process
◦ Term is short for a “sequential process”
◦ Frequently described as “an instance of a program in execution”
◦ The primary means by which multiprogramming / multitasking is
offered in modern operating systems
 A process generally consists of:
◦ The program’s instructions (aka. the “program text”)
◦ CPU state for the process (program counter, registers, flags, …)
◦ Memory state for the process
◦ Other resources being used by the process
 A primary task of the OS is to manage processes
◦ Maintain the illusion of multiple processes executing concurrently by
giving each process a portion of time on the CPU
◦ Handle other stages of the process lifecycle
 Process: is an instance of program execution.
 Program : is a set of process, that may be single or more depending upon
simplicity and complexity of task, include set of syntax, pertaining to a
particular PL.
 Process lifecycle can be represented as a state diagram
 Processes must be created before they can run
 Generally, there is a set of processes that is able to make progress (i.e. not
waiting for I/O to complete, etc.)
 Only one process may be running on each CPU at a time
 When a process is in “running” state, it holds the CPU!
 Other processes that could run, but don’t currently have the CPU, are in the
“ready” state
 New processes don’t necessarily get the CPU right away
◦ They initially go into the collection of “ready” processes
 The OS only allows the currently running process to hold the CPU for a
specific amount of time…
 • When time-slice expires, running process is preempted, and the OS
chooses another process to get the CPU
 Processes often perform long-running tasks
◦ e.g. read from hard disk, network, or some other external device
◦ e.g. process waits for another process (e.g. a signal or termination)
◦ The process becomes blocked until the resource is available
 • Instead of holding everyone up, kernel removes process from CPU, and chooses
another ready process to run.
 When the long-running task is completed, the blocked process can resume
execution
◦ Process is moved back into the ready state
◦ Will eventually be chosen by the OS to run on the CPU again
 Processes eventually terminate
◦ May live for seconds, hours, months, …
 Several tasks must be completed at process termination
◦ Any “at-exit” operations must be performed
◦ Reclaim resources the process is still holding
◦ Other processes may need to observe terminating process’ status
 Processes can terminate for several different reasons
◦ Voluntary termination by the process itself (e.g. it calls exit() or returns from
main(), either with success or error status
◦ Involuntary termination due to an unrecoverable fault in the process (e.g.
segmentation fault due to dereferencing a NULL pointer)
◦ Involuntary termination due to a signal from another process (e.g. another process
issues a SIGINT (^C), SIGTERM or SIGKILL
 This state diagram is sufficient for most OS needs…
 Frequently, other states are also introduced to provide additional capabilities
 Common feature: ability to suspend / resume processes
◦ A suspended process will not be scheduled until it is resumed
◦ A user can suspend a process with e.g. Ctrl-Z at command shell
◦ A process can send SIGSTOP to another process to suspend it
 The process being suspended might also have been blocked on a long-running
operation…
◦ Introduce another state to manage such processes

1 OS Lecture

Uploaded by

Copyright:

Available Formats

1 OS Lecture

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1 OS Lecture

Uploaded by

Copyright:

Available Formats

Dr Anil Kumar

•Single user systems, portable.

•Single user, multiple computers

You might also like