Threads

  1. Motivation
    1. Keep programs interactive
    2. Background save
    3. Multiple clients
  2. Basic idea
    1. multiple lightweight processes
    2. single address space
    3. synchronization primitives available
    4. i/o services available
    5. api can be adapted to program’s needs
  3. So what’s a thread?
    1. stack
    2. program counter (perhaps pushed onto stack?)
    3. what about i/o, signals, global variables (errno?)?
  4. Is it managed from user or kernel?
    1. user threads have very cheap task context switch
    2. kernel threads handle blocking i/o cleanly
    3. extended models for i/o can simplify user threads
      1. select() indicates which files are ready to transfer data
      2. i/o via control block, special signal indicates completion
      3. preemption can be implemented via signal
        1. should threads be preempted?
          1. easier programming model if processes yield() the processor.
          2. nuisance to program with extra yield() calls
          3. preemption can be controlled with special noprempt regions
  5. So how do you use threads?
    1. User interface/computation/io handled seperately (browser)
    2. pop-up server threads
  6. Does it make a difference whether threads may execute in parallel?
    1. depends if there’s pre-emption
  7. Thread primitives (case study: Distributed Computing Environment’s (DCE) thread package.
    1. execution management
      1. create/exit/join/detach
    2. thread template
      1. handy receptacle for common thread params
      2. create/delete
      3. priority
      4. stack size
      5. mutex params
    3. mutex
      1. create/delete
      2. lock/trylock/unlock
      3. two flavors
        1. fast
          1. can deadlock on self
        2. friendly
          1. won’t deadlock on self
      4. not defined whether count like semaphores or instead have signal/wait semantics
        1. OOPS!