open issues:
Open book or not?
"1 page, 2 sided, hand written
cheat sheet" which is to be
turned in w/exam.
no mechanically reproduced content
8.5x11


you will be writing and/or debugging
code.

don't make test too long.



* what is different between
 fork (creates child proc) 
 and exec (execs from w/in existing
 proc)?

* unnamed pipe is created bewt
  child and parent procs.

  know how to code these things.


* signalling.  you set up a 
 handler for certain signals;
 your handler gets called when
 the signal is received.

 kill ( pid, sig-type)
  SIGTERM, SIGINT, SIGKILL
  SIGFAULT

 some can be handled, some cannot
 (KILL).

uses interrupt-like mechanism.
(main code interrupted, 
 handler runs,
 main code resumes where it left
 off).

* schedulers.
* immed switch out blocked procs.
round-robin (gives everybody a turn)
but:
i/o bound procs will get short 
  shrift.
reduce quantum, but increases
  overhead.
change "priority" based on past
  history. (e.g., based on 
  last cpu --> pick the one
  that had used the least
  cpu last [oh no, then the
  short ones will take over]
  instead, use total cpu / lifetime 
  )
schemes that allow preset priorityies,
so some procs are more important
than others.

describing a scheme and asking
you to code it,
or --
coding a scheme and asking you
to describe it
or --
it's partly coded but broken,
and you have to fix it according
to described scheme.
using OSP framework.

.)

you should understand
find_random_priority_pcb()

threads won't be on midterm.

race conditions / need for
semaphone

mutex-like device
protects crit regions of code
and solves race problem.

lock variables & busy waiting
* or disable ints in a single-CPU env.
* "TSL" hw support is required
(in a multi-CPU) env
wasteful of cpu time

strict alternation &
**petersons** pre-semaphore 
solutions to providing
mutex.

semaphone (Dijkstra's invention)

P (down) opn --
  if value > 0, -1, otherwise
  sleep on semaphore

V (up) opn --
  if sleepers, wake one
  otherwise +1 to value

understand & be able to design/
debug mutex algorithms.

also, understand/design/debug
producer-consumer problem.
pg 112.

deadlocks will not be on test.

ch 2, up until pp 114.

also, ch2 scheduling:
pp 132-end (don't worry about 
batch systems).