Professional Documents
Culture Documents
Operating Systems: Chapter 5: Input/Output
Operating Systems: Chapter 5: Input/Output
Chapter 5: Input/Output
5.1: Principles of I/O Hardware
5.1.1: I/O Devices
• Not much to say. Devices are varied.
• Block versus character devices:
• Devices, such as disks and CDROMs, with addressable chunks (sectors in this case) are called block devices,
These devices support seeking.
• Devices, such as Ethernet and modem connections, that are a stream of characters are called character devices.
These devices do not support seeking.
• Some cases, like tapes, are not so clear.
Using a controller
Think of a disk controller and a read request. The goal is to copy data from the disk to some portion of the central memory. How do we do
this?
• The controller contains a microprocessor and memory and is connected to the disk (by a cable).
• When the controller asks the disk to read a sector, the contents come to the controller via the cable and are stored by the controller in
its memory.
• The question is how does the OS, which is running on another processor, let the controller know that a disk read is desired and how is
the data eventually moved from the controllers memory to the general system memory.
• Typically the interface the OS sees consists of some device registers located on the controller.
• These are memory locations into which the OS writes information such as sector to access, read vs. write, length, where in
system memory to put the data (for a read) or from where to take the data (for a write).
• There is also typically a device register that acts as a ``go button''.
• There are also devices registers that the OS reads, such as status of the controller, errors found, etc.
• So now the question is how does the OS read and write the device register.
• With Memory-mapped I/O the device registers appear as normal memory. All that is needed is to know at which address
each device regester appears. Then the OS uses normal load and store instructions to write the registers.
• Some systems instead have a special ``I/O space'' into which the registers are mapped and require the use of special I/O
instructions to accomplish the load and store. From a conceptual point of view there is no difference between the two models.
Homework: 2
5.1.3: Direct Memory Access (DMA)
• With or without DMA, the disk controller pulls the desired data from the
disk to its buffer (and pushes data from the buffer to the disk).
• Without DMA, i.e., with programmed I/O (PIO), the cpu then does loads
and stores (or I/O instructions) to copy the data from the buffer to the
desired memory location.
• With a DMA controller, the controller writes the memory without
intervention of the CPU.
• Clearly DMA saves CPU work. But this might not be important if the
CPU is limited by the memory or by system buses.
• Very important is that there is less data movement so the buses are used
less and the entire operation takes less time.
• Since PIO is pure software it is easier to change, which is an advantage.
• DMA does need a number of bus transfers from the CPU to the controller
to specify the DMA. So DMA is most effective for large transfers where
the setup is amortized.
• Why have the buffer? Why not just go from the disk straight to the
memory.
Answer: Speed matching. The disk supplies data at a fixed rate, which
might exceed the rate the memory can accept it. In particular the memory
might be busy servicing a request from the processor or from another
DMA controller.
Homework: 5
Note: I improved the presentation of disk controllers given last time (unfortunately, this was very easy to do). In particular, I suggest you
read the new small section entitled ``Using a controller''. Both the giant page and the page for lecture-11 now include this new section.
5.2: Principles of I/O Software
As with any large software system, good design and layering is important.
Device independence
We want to have most of the OS, unaware of the characteristics of the specific devices attached to the system. Indeed we also want the OS to
be largely unaware of the CPU type itself.
Due to this device independence, programs are written to read and write generic devices and then at run time specific devices are assigned.
Writing to a disk has differences from writing to a terminal, but Unix cp and DOS copy do not see these differences. Indeed, most of the OS,
including the file system code, is unaware of whether the device is a floppy or hard disk.
Uniform naming
Recall that we discussed the value of the name space implemented by file systems. There is no dependence between the name of the file and
the device on which it is stored. So a file called IAmStoredOnAHardDisk might well be stored on a floppy disk.
Error handling
There are several aspects to error handling including: detection, correction (if possible) and reporting.
1. Detection should be done as close to where the error occurred as possible before more damage is done (fault containment). This is not
trivial.
2. Correction is sometimes easy, for example ECC memory does this automatically (but the OS wants to know about the error so that it
can schedule replacement of the faulty chips before unrecoverable double errors occur).
Other easy cases include successful retries for failed ethernet transmissions. In this example, while logging is appropriate, it is quite
reasonable for no action to be taken.
3. Error reporting tends to be awful. The trouble is that the error occurs at a low level but by the time it is reported the context is lost.
Unix/Linux in particular is horrible in this area.
should print a value one greater than that read. But if the assignment is
performed before the read completes, the wrong value is assigned.
• Performance junkies sometimes do want the asynchrony so that they can have
another portion of their program executed while the I/O is underway. That is
they implement a mini-scheduler in their application code.
Layering
Layers of abstraction as usual prove to be effective. Most systems are believed to use
the following layers (but for many systems, the OS code is not available for
inspection).
1. User level I/O routines.
2. Device independent I/O software.
3. Device drivers.
4. Interrupt handlers.
We give a bottom up explanation.
3. The driver jumps to the scheduler indicating that the current process should be blocked.
4. The scheduler blocks A and runs (say) B.
5. B starts running.
6. An interrupt arrives (i.e., an I/O has been completed).
7. The interrupt handler invokes (the bottom part of) the driver.
A. The driver informs the main line perhaps passing data and surely passing status (error, OK).
B. The top part is called to start another I/O if the queue is nonempty. We know the controller is free. Why?
Answer: We just received an interrupt saying so.
8. The driver jumps to the scheduler indicating that process A should be made ready.
9. The scheduler picks a ready process to run. Assume it picks A.
10.A resumes in the driver, which returns to the main line, which returns to the user code.
D. Protection. A wide range of possibilities are actually done in real systems. Including both extreme examples of everything is
permitted and nothing is permitted (directly).
1. In ms-dos any process can write to any file. Presumably, our offensive nuclear missile launchers do not run dos.
2. In IBM and other mainframe OS's, normal processors do not access devices. Indeed the main CPU doesn't issue the
I/O requests. Instead an I/O channel is used and the mainline constructs a channel program and tells the channel to
invoke it.
3. Unix uses normal rwx bits on files in /dev (I don't believe x is used).
E. Buffering is necessary since requests come in a size specified by the user and data is delivered in a size specified by the
device.
F. Enforce exclusive access for non-shared devices like tapes.
Homework: 6, 7, 8.
5.3: Disks
The ideal storage device is
K. Fast
L. Big (in capacity)
M.Cheap
N. Impossible
Disks are big and cheap, but slow.
BE.Profiling
1. Want a histogram giving how much time was spent in each 1KB (say) block of code.
2. At each tick check the PC and bump the appropriate counter.
3. At the end of the run can assign the 1K blocks to software modules.
4. If use fine granularity (say 10B instead of 1KB) get higher accuracy but more memory overhead.
Homework: 12
5.5: Terminals
5.5.1: Terminal Hardware
Quite dated. It is true that modern systems can communicate to a hardwired ascii terminal, but most don't. Serial ports are used, but
they are normally connected to modems and then some protocol (SLIP, PPP) is used not just a stream of ascii characters.
Keyboards
Tanenbaum description of keyboards is correct.
BJ.At each key press and key release a code is written into the keyboard controller and the computer is interrupted.
BK.By remembering which keys have been depressed and not released the software can determine Cntl-A, Shift-B, etc.
6.1: Resources:
The resource is the object granted to a process.
• Resources come in two types
1. Preemptable, meaning that the resource can be taken away from its current owner (and given back later). An example is
memory.
2. Non-preemptable, meaning that the resource cannot be taken away. An example is a printer.
• The interesting issues arise with non-preemptable resources so those are the ones we study.
• Life history of a resource is a sequence of
1. Request
2. Allocate
3. Use
4. Release
• Processes make requests, use the resourse, and release the resourse. The allocate decisions are made by the system and we will study
policies used to make these decisions.
6.2: Deadlocks
To repeat: A deadlock occurs when a every member of a set of processes is waiting for an event that can only be caused by a member of the
set.
Often the event waited for is the release of a resource.
On the board draw the resource allocation graph for various possible executions of the processes, indicating when deadlock occurs and when
deadlock is no longer avoidable.
There are four strategies used for dealing with deadlocks.
1. Ignore the problem
2. Detect deadlocks and recover from them
3. Avoid deadlocks by carefully deciding when to allocate resources.
4. Prevent deadlocks by violating one of the 4 necessary conditions.
Preemption
Perhaps you can temporarily preempt a resource from a process. Not likely.
Rollback
Database (and other) systems take periodic checkpoints. If the system does take checkpoints, one can roll back to a checkpoint whenever a
deadlock is detected. Somehow must guarantee forward progress.
Kill processes
Can always be done but might be painful. For example some processes have had effects that can't be simply undone. Print, launch a missile,
etc.
3. The banker now pretends that P has terminated (since the banker knows that it can guarantee this will happen). Hence the banker
pretends that all of P's currently held resources are returned. This makes the banker richer and hence perhaps a process that was not
eligible to be chosen as P previously, can now be chosen.
4. Repeat these steps.
Example 1
• One resource type R with 22 unit process claim current
• Three processes X, Y, and Z with claims 3, 11, and 19 respectively. X 3 1
• Currently the processes have 1, 5, and 10 units respectively.
Y 11 5
• Hence the manager currently has 6 units left.
• Also note that the max additional needs for processes are 2, 6, 9 Z 19 10
• So the manager cannot assure (with its current remaining supply of 6 units that Z can terminate. But that is total 16
not the question.
• This state is safe
1. Use 2 units to satisfy X; now the manager has 7 units.
2. Use 6 units to satisfy Y; now the manager has 12 units.
3. Use 9 units to satisfy Z; done!
Example 2
Assume that Z now requests 2 units and we grant them. process claim current
• Currently the processes have 1, 5, and 12 units respectively. X 3 1
• The manager has 4 units. Y 11 5
• The max additional needs are 2, 6, and 7. Z 19 12
• This state is unsafe
total 18
1. Use 2 unit to satisfy X; now the manager has 5 units.
2. Y needs 6 and Z needs 7 so we can't guarantee satisfying either
• Note that we were able to find a process that can terminate (X) but then we were stuck. So it is not enough to find one process. Must
find a sequence of all the processes.
Remark: An unsafe state is not necessarily a deadlocked state. Indeed, if one gets lucky all processes may terminate successfully. A safe
state means that the manager can guarantee that no deadlock will occur.
6.7.3: Starvation
As usual FCFS is a good cure. Often this is done by priority aging and picking the highest priority process to get the resource. Also can
periodically stop accepting new processes until all old ones get their resources. The End: Good luck on the final
http://cs.nyu.edu/~gottlieb/courses/2000-01-spring/os/chapters/chapter-1.html