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