Lecture #8

Administrivia

• minor revisions to Ass 2 by end of Friday

Previously on CSS503A...

• dining philosophers problem

• sleeping barbers problem

  • assignment 2

• gridlock: (automobile) traffic version of deadlock

TODO: diagram

• deadlock: mutual dependency

• in practice: OS lets user deal with deadlock

  • "why is this taking so long?"

• prevention

• detection & recovery

• OS may not avoid deadlock, but your system should -- if possible

  • favorite approach: strict ordering of resources

• 4 conditions

  1. mutual exclusion (exclusive access to resources)
  2. hold & wait
  3. no preemption
  4. circular wait

• 2-color graph: resources & processes

TODO: diagram

• graph algorithm: find loops (cycles)

  • DFS or BFS

• avoidance: attack one of the four conditions

  1. disallow mutual exclusion
  2. disallow hold or wait
  3. allow preemption
  4. prevent circular wait
     • strict ordering of resources

• detection & recovery

  • detection: construct resource allocation graph & look for cycles
  • recovery: kill process(es) until no cycle

Banker's Algorithm

• multiple instances of similar resources (resource classes)

  • can't use resource graph

• each process must declare (in advance) its maximum resource requirements

• resource requests will be granted only if the algorithm can demonstrate that there exists some sequence such that all processes can successfully acquire & release resources

  • if an allocation sequence cannot be demonstrated, the requesting process must wait until other process(es) releases enough resources such that the request may be granted at that time

Prerequisites

M = # resource classes
N = # processes

Available[M] = # resources available for each class (0..M-1)
Max[N,M] = maximum demand for each resource, for each process
Allocation[N,M] = current allocation of each resource, for each prosess
Need[N,M] = Max - Allocation
   # each row is a vector with one element for each resource class

define X < Y  iff for all i in [0..M-1], X[i] < Y[i]

• note: X < Y is a partial ordering. It is posible for some X ≠ Y that neither X < Y nor Y < X

Safety algorithm

# Safety algorithm (lemma? subroutine?)
Work[M]
Finish[N]

Work = Available # currently available resources
Finish = False[N]
loop:
  find process i such that its maximum request could be satisfied (i.e. !Finish[i] & Need[i] < Work)
  if no such i:
    system is safe iff Finish == True[N]
    return
  # assume process i gets it's max request and is allowed to run to completion
  # then it's currently-held resources become available
  Work += Allocation[i]

• the idea is to maintain state such that, at any point in time, there exists a potential allocation sequence that doesn't result in a deadlock
  • this may or may not be the actual sequence; just showing the existence of at least one valid sequence

Allocation algorithm:

Request[i][M] = request vector of process i
if Request[i] > Need[i]
  raise exception
if Request[i] > Available
  wait
if system would be unsafe after allocation
  wait
otherwise
  grant requested resource

Example:

resources: A = 10, B = 5, C = 7
current Available = (3, 3, 2)
    max        current    need (max - current)
P0  (7, 5, 3)  (0, 1, 0)  (7, 4, 3)
P1  (3, 2, 2)  (2, 0, 0)  (1, 2, 2)
P2  (9, 0, 2)  (3, 0, 2)  (6, 0, 0)
P3  (2, 2, 2)  (2, 1, 1)  (0, 1, 1)
P4  (4, 3, 3)  (0, 0, 2)  (4, 3, 1)

• <P1, P3, P4, P0, P2> satisfies safety
  • P1's maximal request could be satisfied immediately
  • P0, P4 would have to wait

File System--Interface

• devices

  • character-at-a-time
    • keyboard
    • tty
    • speaker
  • block-at-a-time (record-oriented)
    • punch card
    • line/page printer
    • disk (sectors)

• access method

  • sequential
    • tape
    • tty
    • punch card
    • pipe (pseudo device)
  • random-access
    • disk
    • flash
    • bit-mapped screen

• direction

  • input only
    • card reader
    • keyboard
  • output only
    • printer/card punch
    • bit-map screen
  • input/output
    • disk
    • tape
    • flash

• disk drive: mechanical device

  • electric impulses: stepper motor, read/write head
  • controller (hardware) sends impulses
    • software interface: read block i, write block j
      • block address may be tuple (cylinder, track, sector)
  • device driver (software)
    • provides higher-level operations, common interface
      • your low level is my high level
    • data is linear sequence of blocks (0..N-1)
      • sub-block read: read entire block, extract byte(s)
      • sub-block write: read entire block, modify bytes, write entire block

• working with raw devices: inconvienient

  • files: higher level of abstraction
    • filesystem: data structure superimposed on array of blocks

• file abstraction

  • non-volatile storage (except tmpfs)
  • logically contiguous space
  • attributes:
    • name
    • type
    • size
    • protections/permissions
    • time/date (create/access/modify)
    • ownership (user, workgroup)

• disk is shared by multiple users: require permissions & ownership

• file location

  • user view: directory
  • kernel/physical view: list of block numbers

• format

  1. record structure
     • sequence of bytes
     • fixed-size record (block) (80 bytes, 512 bytes, ...)
       • random access: like array index
     • variable-size: record separator (e.g. newline)
     • random-access variable-size records (ISAM/VSAM)
       • B-Tree
  2. data format
     • text
     • binary (application-specific)
       • e.g Word doc, ELF, zip
       • with or without OS support

• file type: "extension"

  • meaningful on some systems
  • meaningful to some applications
  • ignored by Unix/Posix/Linux systems
    • file extension is just a convention

• magic number: fast identifer check on file format

  • application-specific
  • heuristic
    • if magic number is absent, file is not that kind
    • if magic number is present, file may be that kind

• Unix file command: heuristic

Basic File Operations

• open

  • open existing file
  • create file if it doesn't exist
  • only open (create) new file
    • atomic operation: may be used for synchronization
    • fails with NFS (network file system)
  • open for reading/writing/both
  • set initial value of file pointer to beginning/end
    • append-only mode

• read

  • read specified number of bytes, advance file pointer

• write

  • write specified number of bytes, advance file pointer

• close

  • flush cached data to disk
  • release resources (buffers, handle)

• tell

  • return current file pointer position

• seek

  • reposition file pointer
    • may return failure if (device) file does not support the operation (e.g. can't go backwards on keyboard)

• ioctl

  • general interface for device-specific operation

• fcntl

  • file parameters (e.g. get/set close-on-exec flag)

Unix-like (Posix)

fd = open(fname, O_RDONLY)

fd = open(fname, O_WRONLY, S_IRUSR|S_IWUSR)

n = read(fd, array_buf, n_read)

n = write(fd, array_buf, n_write)

close(fd)