lecture 6:  more osp scheduling, threads

went over fred's least-cpu scheduler.
seemed to do well, but has a serious conceptual bug!
older processes are treated the same as newer ones -->
      all proc's end up with equal cpu time, regardless of how long
      they have been running!
this will 'starve' old processes.
should involve the pcb field that tells when the cpu was created, and
normalize avg time over its lifetime.

processes are 2 things:  

* resource grouping (addr space, globals, open files, child procs,
  alarms, signals, etc)

* execution state (pc, regs, stack, other state)

threads let you share the proc. resources but have separate exec
state.

examples:

MS Word
 -- interaction thread (keyboard, mouse, typing)
 -- background reformatting thread
 -- autosave thread

Web server
 -- receive HTTP req's
 -- process them

Web browser
 -- retrieve multiple files (images) in parallel

3 ways to construct a server:
* threads (parallelism, blocking system calls)
* single-threaded (no parallelism, blocking calls)
* state machine (parallelism, non-blocking, interrupts)

USER SPACE OR KERNEL?

user space:
- less resources in kernel/system
- thread yields let the proc's thread scheduler pick a diff thread, so
proc doesn't yield, gets its fair share of cpu, no excessive paging
- proc can implement its own thread scheduler based on its own needs
- BUT:  if a thread blocks, the system thinks the whole proc is
blocked!
  - can use non-blocking calls, but it's a pain
  - with paging, the whole proc will get switched out, even if other
    threads are paged in and could run
- threads must explicitly yield (implementing tick-based round-robin
scheduler is messy)
- the biggie is need to make system calls and it not being necessary
to use the non-blocking forms all the time.

kernel:
-- recycling threads
-- hybrid