INPUTOUTPUT

1
INPUT/OUTPUT

• Operating system controls all I/O devices
• Two aspects of I/O devices are important for
  operating system
• I/O hardware
• I/O software

2
Principles of I/O Hardware

• I/O devices
• Block Devices stores information in fixed-size
  blocks Disk (seek operation)
• Character Devices Delivers or accept a stream of
  characters, without regards to any block
  structure Printer, network interfaces,
• Data rates of some common devices are presented
  in the next slide

3

4
Device controllers

• I/O units consist of mechanical and electronic
  component (electronic component called device
  controller or adapter)
• O.S initialize the controller with few parameters
  and controller take care of the rest. For example
  if a disk formatted with 256 sectors of 512 bytes
  a serial bit stream of 4096 bits with all
  necessary information is come off the drive.
  Controller assembles the bits and changes the
  bits into the bytes and send them to main memory

5
Device controllers

6
Device controllers

7
Memory-Mapped I/O

• Each controller has few register and maybe a data
  buffer (e.g. video RAM) to be able to communicate
  with CPU
• CPU communicates with the control registers and
  data buffer in three ways
• 1- With assigned I/O port of that device
• IN R0,4 reads the contents of port 4
• MOV R0,4 reads the contents of
  memory word 4 and put it
  in R0.

8

9
Memory-Mapped I/O

• 2- Memory-mapped I/O means the
• registers are part of the memory address (b
  in the previous slide)
• 3- Hybrid scheme It has memory-mapped I/O data
  buffers and separate I/O ports for control
  registers
• In all of these cases the communication with CPU
  is through the buses

10
Memory-Mapped I/O

• Disadvantage of Separate I/O and memory space
• In C/C we dont have IN or OUT commands to read
  the ports
• Some of the advantages of Memory-mapped I/O
• The device driver can be written entirely in
  C/C
• Every instructions that can reference memory can
  also reference control registers

11
Communication with I/O Devices

• If there is only one address bus all the I/O
  devices and memory modules can check memory
  references by examining this bus (see a in the
  next slide)
• But most of the systems has a dedicated
  high-speed memory bus for optimizing memory
  performance (see b in the next slide). The
  problem with this design for memory-mapped I/O
  is I/O devices have no way of seeing memory
  addresses because they go by on the memory bus.

12
Communication with I/O Devices

13
Communication with I/O Devices

• One possible solution for the system with
  multiple buses is to first sending all memory
  references to the memory. If the memory fails to
  respond , then CPU tries other buses.
• Pentium solves this problem by filtering
  addresses in the PCI bridge chip. This chip
  checks the range of memory address references, if
  it finds non-memory references, it forwards them
  onto PCI (Peripheral Component Interconnect) bus
  instead of memory bus (see next slide)

14

15
Direct Memory Access (DMA)

• Instead of using CPU for exchanging data with
  different controllers DMA is often used.
• DMA has access to the system bus independent of
  CPU and it can be programmed by the CPU to
  exchange data (next slide shows how DMA works).

16

17
Principles of I/O Software

• Goals of the I/O software
• 1- Device independence It should be possible to
  write programs that can access any I/O device
  without having to specify the device in advanced.
  For example
• sortltinputgtoutput should work for floppy disk
  , IDE or SCSI disk

18
Principles of I/O Software

• 2- Uniform naming The name of the device should
  be simply an string or a integer that is not
  depending on the device. For example by mounting,
  each device can be addressed by file path name
• 3- Error handling Error should be handled close
  to the hardware

19
Principles of I/O Software

• 4-Syncrhronous(blocking) vs. asynchronous
  (interrupt-driven) transfer. Most physical I/O
  are asynchronous but users program can be written
  much easier if they write with blocking I/O
  operations
• 5- Buffering, shareable and dedicated devices.

20
Principles of I/O Software

• Goals of the I/O software can be achieved by
  structuring the software in following layers

21
Interrupt Handler

• The device driver blocks when it performs I/O
  operation.
• When I/O completes, the controller issues
  interrupt and interrupt handler runs interrupt
  service procedure
• Finally interrupt handler unblocks the driver,
  therefore its role is hiding the I/O controller
  interrupts.

22
Device Drivers

• The device drivers command the controllers by
  setting controller registers
• The device driver for each controller is created
  by devices manufacturer and should be put into
  the kernel
• O.S. should have an architecture to allow the
  installation of different device drivers. Device
  drivers usually positioned below the rest of O.S.
  (see the next slide)

23
(No Transcript)
24
Device Drivers

• The most important function of device driver is
  changing abstract read/write request issued by
  device-independent software above it to concrete
  form.
• For example a disk driver converts a linear block
  number into head, track, sector and cylinder of
  the related disk.
• Device driver can queue the requests and report
  the errors to their callers.

25
Device-Independent I/O Software

• Driver contains device dependent codes. Some
  other functions that are common to all devices
  and can be used as the interface to the
  user-level software are in the
  device-independent software
• The basic functions of the device-independent I/O
  software are presented in the next slide

26
Device-Independent I/O Software
27
Uniform Interfacing for Device Drivers

• It means O.S. should have common functions such
  as naming and protection for different drivers.
• For example in Unix the name of /dev/disk0 can
  be mapped to locate any driver. It contains the
  i-node that contained the address of that device.
• Also both Unix and Windows have the protection
  method that can be used for all devices
  uniformly.

28
Without standard driver interface
With standard driver interface
29
Device-Independent I/O Software

• Buffering can be used both in the user space and
  kernel space. With buffering O.S. stores the data
  from devices that have different speed (see next
  slide)
• Error Reporting The general errors (not device
  dependent errors) is handled by O.S. For example
  reading or writing the wrong device

30
Buffering

31
Device-Independent I/O Software

• Allocating and Releasing dedicated devices is
  done by O.S. For example O.S. does not allow
  acquiring a device that is not available. Also
  O.S. keeps a queue of the processes that are
  requested the same device
• Device-independent software provide a unique
  block size (from different disks with different
  sector sizes) to the higher layer.

32
User-Space I/O software

• The collection of library procedures such as
• count write( fd, buffer, nbytes)
• scanf, printf commands
• Spooling. For example spool printer. Process
  first put the file in spool directory and daemon
  (the only process having permission to the
  printer) print the file in the directory.

33
Summary of I/O System
34
Disks

• A groups of magnetic disks organized into
  cylinders is the example of I/O devices
• The IDE (Integrated Drive Electronics) disks have
  sophisticated drives contains microcontrollers
  for doing some of the work of the real disk
  controller
• Disk controllers may do multiple seeks (i.e.,
  overlapped seeks) on drives
• Next slide compares an early floppy disk with a
  modern hard disk

35

36
Disks

• On older disks the number of sector per track was
  the same for all cylinders
• Modern disks are divided into zones with more
  sectors on the outer zones than inner zones (see
  the next slide)
• To hide the details of how many sectors each
  track has, most modern disks presents a virtual
  geometry to the O.S. (see next slide)

37

Virtual geometry
Disk with two zones
38
Disks

• The software acts as there are x cylinders, y
  heads and z sectors per track.
• Controller remaps a request for (x,y,z) onto real
  cylinder, head and sector
• The max value for Pentium is (65535, 16 and 63)
  means max capacity of disk with 512 bytes per
  sector is 31.5 GB
• To get around this limit logical block
  addressing, in which disk sectors are just
  numbered consecutively starting at 0, is used

39
Disk Formatting

• Before the disk can be used, each plotter must
  receive a low-level format done by software. It
  means tracks contain some number of sectors with
  following format
• The start of each sector is recognized by
  hardware by a certain bit pattern (named
  preamble) and ECC contains information that can
  be used for recovery

40
Disk Formatting

• After low level format each sector in the track
  is identified by a number.
• Cylinder skew means offsetting the position 0 of
  each track from the previous track to improve the
  performance (see next slide). It is done to allow
  the disk to read multiple tracks in one
  continuous operation without loosing data

41

42
Disk Formatting

• Reading the sectors continuously requires a large
  buffer in the controller
• But if controller has a buffer just for one
  sector and wants to read to consecutive sectors,
  after reading the first one, its data must
  transfer to memory. While controller transfers
  the first sector, the next sector will be passing
  under the disk head and controller can not buffer
  its arriving bits.
• This problem can be solved by numbering the
  sectors in an interleaved fashion when formatting
  the disk. See next slide

43

No interleaving Single
interleaving Double interleaving

44
Disk Formatting

• After low-level format the disk is partitioned
• On Pentium sector 0 contains the partition table
• Finally high-level format prepare a disk for use
  by formatting each partition separately. It means
  storage administration (free list or bit map),
  root directory, empty file system and etc. are
  created for each partition

45
Disk Arm Scheduling Algorithm

• For most disks, the seek time delay dominates the
  other two delays (rotational and data transfer
  delay) so the lower layers of O.S. ( for example
  device driver or even controller if it accepts
  multiple requests) try to reduce the disk seek
  time
• Many disk drivers maintain a table, indexed by
  cylinder number, with all the pending requests
  for each cylinder
• By using this structure following algorithms can
  be used for serving the requests

46
FCFS

• If disk driver accepts request as First Come
  First Served (FCFS) little can be done to
  optimize disk seek time
• For example suppose while seek to cylinder 11 is
  in progress, new requests come for 1,36,16,34, 9
  and 12. FCFS requires total arm motion of 111
  cylinders

47
Shortest Seek First (SSF)

• Always handles the closet request next, to
  minimize the disk seek time
• Its performance is better than FCFS but the
  problem is the requests far from the middle may
  get poor service (not a fair algorithm)
• As previous example current request is for
  cylinder 11 and requests come for 1,36,16,34, 9
  and 12. SSF requires total arm motion of 61
  cylinders

48
Elevator Algorithm

• Head keeps moving in the same direction (same as
  elevators) until there are no more outstanding
  requests in that direction, then head switches
  the direction (it is also called SCAN algorithm)
• Same Example Current request is for cylinder 11
  and requests come for 1,36,16,34, 9 and 12.
  Elevator algorithm requires total arm motion of
  60 cylinders

49
Elevator Algorithm

• Software should maintain 1 bit to know the
  direction. Elevator also should know whether it
  is going UP or DOWN
• Elevator algorithm is usually worse than SSF but
  for previous example it is slightly better

50
Deadlock

• In the Multiprogramming environment processes
  compete for the resources
• Resources can be preemptable resource that means
  it can be taken away from the process owning it
  with no ill effects (such as memory)
• A nonpreemptable resource is the one that cannot
  be taken away from its current owner without
  causing the computation to fail

51
Deadlock

• Deadlock can be defined as follows
• A set of processes is deadlocked if each process
  in the set is waiting for an event that only
  another process in the set can cause
• Resource graph can be used to show a deadlock
  (see the next slide)

52
Deadlock

Holding a resource
Requesting a resource
Deadlock
53
Conditions for Deadlock

• 1- Mutual Exclusion At least one resource must
  be non-sharable. Only one process at a time can
  use the resource. All other requesting processes
  must be delayed until resource is released
• 2-Hold and wait There must exist a process that
  is holding one resource and waiting to acquire
  additional resources held by other processes

54
Conditions for Deadlock

• 3-No preemption condition Resource can not be
  preempted. It means a resource can only be
  released voluntarily by the process holding it
• 4-Circular wait There must be a circular chain
  of two or more processes, each of which is
  waiting for a resource held by the next member of
  the chain

55
Deadlock Modeling

• Resource allocation graph facilitates viewing of
  system states and detecting deadlocks (see next
  slide). Two simple ways to avoid deadlock are
  presented here. A detailed discussion will come
  later.
• If Operating System decides to run all of the
  processes sequentially, this ordering (i.e.,
  sequential) does not lead to any deadlocks but
  there is no parallelism at all
• If granting a particular request might lead to
  deadlock O.S. can simply suspend the process (not
  scheduling the process). See next slides

56

57

58
Methods for Handling Deadlock

• Ignoring deadlocks (Unix) (Window)
• Deadlock detection and recovery
• Deadlock prevention, deadlock avoidance by
  negation one of the four required conditions
• Dynamic avoidance by careful resource allocation

59
Deadlock Detection and Recovery

• Every time a resource is requested or released,
  the resource graph is updated and a check is made
  to see if any cycle exist. If a cycle exists, one
  of the processes in the cycle is killed. If it
  does not break the deadlock, another process is
  killed, and so on until the cycle is broken
• Another way is periodically check to see if there
  are any process that has been blocked for a long
  time. Such processes are then killed

60
Deadlock Prevention

• Attempt to prevent deadlock by ensuring that one
  of the 4 necessary conditions does not hold
• Mutual Exclusion If no resource were ever
  assigned exclusively to a single process, we
  would never have deadlocks. For example By
  spooling printer, since Daemon never requested
  any other resources, we can eliminate deadlock
  for the printer. In general this method is
  difficult because not all devices can be spooled.
  Also by spooling printer we can not eliminate
  the competition for the disk space that is
  required for spooling. This competition can lead
  to deadlock

61
Deadlock Prevention

• Hold and Wait How do we ensure this condition
  never occurs?
• Each process requests and receives all necessary
  resources before beginning execution. Problem
  they dont know how many resources they will need
  until they have started running
• Require a process requesting a resource to first
  temporarily release all the resources it
  currently holds

62
Deadlock Prevention

• No Preemption It means if we attack the no
  preemption condition we should allow a resource
  such as a printer taken away from a process that
  using it and is waiting for a non available
  plotter. It means this process now waits for
  printer and plotter.

63
Deadlock Prevention

• Circular wait There are some methods to avoid
  circular wait
• To have a rule and say that a process is entitled
  only to a single resource at any moment. If it
  needs a second one, it must release the first
  one.
• To provide a global numbering of all the
  resources. So processes can request resources
  whenever they want to, but all requests must be
  made in numerical order. See the next slide

64
Deadlock Prevention

Numerically ordered
A resource graph
65
Summary of Approaches to Deadlock Prevention

66
Deadlock Avoidance

• Suppose that we do not want to be restricted as
  to forbid existence of any one of the necessary
  deadlock conditions but still want to avoid
  deadlock. One of the way is imposing arbitrary
  rules on processes such as the previous example,
  in which by not scheduling process B the deadlock
  was avoided (see slide_no 57)

67
Deadlock Avoidance

• The system must be able to decide whether
  granting a resource is safe or not and only make
  the allocation when it is safe. For example next
  slide shows how we can use process resources
  trajectories to identify safe and not safe
  regions. In the next slide at t B is requesting a
  resource. If system decide to grant it to B
  system will enter an unsafe region and eventually
  deadlock (intersection of I2 and I6). The shaded
  areas indicate that because of mutual exclusion
  system can not enter these arias. Note that
  printer or plotter can be used by only one
  process. To avoid deadlock, B should be suspended
  until A has requested and released the plotter.

68

• Two Process Resource Trajectories

69
The Bankers Algorithm for a Single Resource

Unsafe
Safe
Safe
70
The Bankers Algorithm for Multiple Resources