doc/threads.tmpl

   1                         +--------------------+
   2                         |        CS 140      |
   3                         | PROJECT 1: THREADS |
   4                         |   DESIGN DOCUMENT  |
   5                         +--------------------+
   6
   7 ---- GROUP ----
   8
   9 >> Fill in the names and email addresses of your group members.
  10
  11 FirstName LastName <email@domain.example>
  12 FirstName LastName <email@domain.example>
  13 FirstName LastName <email@domain.example>
  14
  15 ---- PRELIMINARIES ----
  16
  17 >> If you have any preliminary comments on your submission, notes for the
  18 >> TAs, or extra credit, please give them here.
  19
  20 >> Please cite any offline or online sources you consulted while
  21 >> preparing your submission, other than the Pintos documentation, course
  22 >> text, lecture notes, and course staff.
  23
  24                              ALARM CLOCK
  25                              ===========
  26
  27 ---- DATA STRUCTURES ----
  28
  29 >> A1: Copy here the declaration of each new or changed `struct' or
  30 >> `struct' member, global or static variable, `typedef', or
  31 >> enumeration.  Identify the purpose of each in 25 words or less.
  32
  33 ---- ALGORITHMS ----
  34
  35 >> A2: Briefly describe what happens in a call to timer_sleep(),
  36 >> including the effects of the timer interrupt handler.
  37
  38 >> A3: What steps are taken to minimize the amount of time spent in
  39 >> the timer interrupt handler?
  40
  41 ---- SYNCHRONIZATION ----
  42
  43 >> A4: How are race conditions avoided when multiple threads call
  44 >> timer_sleep() simultaneously?
  45
  46 >> A5: How are race conditions avoided when a timer interrupt occurs
  47 >> during a call to timer_sleep()?
  48
  49 ---- RATIONALE ----
  50
  51 >> A6: Why did you choose this design?  In what ways is it superior to
  52 >> another design you considered?
  53
  54                          PRIORITY SCHEDULING
  55                          ===================
  56
  57 ---- DATA STRUCTURES ----
  58
  59 >> B1: Copy here the declaration of each new or changed `struct' or
  60 >> `struct' member, global or static variable, `typedef', or
  61 >> enumeration.  Identify the purpose of each in 25 words or less.
  62
  63 >> B2: Explain the data structure used to track priority donation.
  64 >> Use ASCII art to diagram a nested donation.  (Alternately, submit a
  65 >> .png file.)
  66
  67 ---- ALGORITHMS ----
  68
  69 >> B3: How do you ensure that the highest priority thread waiting for
  70 >> a lock, semaphore, or condition variable wakes up first?
  71
  72 >> B4: Describe the sequence of events when a call to lock_acquire()
  73 >> causes a priority donation.  How is nested donation handled?
  74
  75 >> B5: Describe the sequence of events when lock_release() is called
  76 >> on a lock that a higher-priority thread is waiting for.
  77
  78 ---- SYNCHRONIZATION ----
  79
  80 >> B6: Describe a potential race in thread_set_priority() and explain
  81 >> how your implementation avoids it.  Can you use a lock to avoid
  82 >> this race?
  83
  84 ---- RATIONALE ----
  85
  86 >> B7: Why did you choose this design?  In what ways is it superior to
  87 >> another design you considered?
  88
  89                           ADVANCED SCHEDULER
  90                           ==================
  91
  92 ---- DATA STRUCTURES ----
  93
  94 >> C1: Copy here the declaration of each new or changed `struct' or
  95 >> `struct' member, global or static variable, `typedef', or
  96 >> enumeration.  Identify the purpose of each in 25 words or less.
  97
  98 ---- ALGORITHMS ----
  99
 100 >> C2: Suppose threads A, B, and C have nice values 0, 1, and 2.  Each
 101 >> has a recent_cpu value of 0.  Fill in the table below showing the
 102 >> scheduling decision and the priority and recent_cpu values for each
 103 >> thread after each given number of timer ticks:
 104
 105 timer  recent_cpu    priority   thread
 106 ticks   A   B   C   A   B   C   to run
 107 -----  --  --  --  --  --  --   ------
 108  0
 109  4
 110  8
 111 12
 112 16
 113 20
 114 24
 115 28
 116 32
 117 36
 118
 119 >> C3: Did any ambiguities in the scheduler specification make values
 120 >> in the table uncertain?  If so, what rule did you use to resolve
 121 >> them?  Does this match the behavior of your scheduler?
 122
 123 >> C4: How is the way you divided the cost of scheduling between code
 124 >> inside and outside interrupt context likely to affect performance?
 125
 126 ---- RATIONALE ----
 127
 128 >> C5: Briefly critique your design, pointing out advantages and
 129 >> disadvantages in your design choices.  If you were to have extra
 130 >> time to work on this part of the project, how might you choose to
 131 >> refine or improve your design?
 132
 133 >> C6: The assignment explains arithmetic for fixed-point math in
 134 >> detail, but it leaves it open to you to implement it.  Why did you
 135 >> decide to implement it the way you did?  If you created an
 136 >> abstraction layer for fixed-point math, that is, an abstract data
 137 >> type and/or a set of functions or macros to manipulate fixed-point
 138 >> numbers, why did you do so?  If not, why not?
 139
 140                            SURVEY QUESTIONS
 141                            ================
 142
 143 Answering these questions is optional, but it will help us improve the
 144 course in future quarters.  Feel free to tell us anything you
 145 want--these questions are just to spur your thoughts.  You may also
 146 choose to respond anonymously in the course evaluations at the end of
 147 the quarter.
 148
 149 >> In your opinion, was this assignment, or any one of the three problems
 150 >> in it, too easy or too hard?  Did it take too long or too little time?
 151
 152 >> Did you find that working on a particular part of the assignment gave
 153 >> you greater insight into some aspect of OS design?
 154
 155 >> Is there some particular fact or hint we should give students in
 156 >> future quarters to help them solve the problems?  Conversely, did you
 157 >> find any of our guidance to be misleading?
 158
 159 >> Do you have any suggestions for the TAs to more effectively assist
 160 >> students, either for future quarters or the remaining projects?
 161
 162 >> Any other comments?