Allow decimal point in percentages.
[pintos-anon] / 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 thread_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 >> thread_sleep() simultaneously?
45
46 >> How are race conditions avoided when a timer interrupt occurs during a
47 >> call to thread_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.
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 ---- RATIONALE ----
122
123 >> Critique your design, pointing out advantages and disadvantages in
124 >> your design choices.  If you were to have extra time to work on this
125 >> part of the project, how might you choose to refine or improve your
126 >> design?
127
128 >> The assignment explains arithmetic for fixed-point math in detail, but
129 >> it leaves it open to you to implement it.  Why did you decide to
130 >> implement it the way you did?  If you created an abstraction layer for
131 >> fixed-point math, that is, an abstract data type and/or a set of
132 >> functions or macros to manipulate fixed-point numbers, why did you do
133 >> so?  If not, why not?
134
135                            SURVEY QUESTIONS
136                            ================
137
138 Answering these questions is optional, but it will help us improve the
139 course in future quarters.  Feel free to tell us anything you
140 want--these questions are just to spur your thoughts.  You may also
141 choose to respond anonymously in the course evaluations at the end of
142 the quarter.
143
144 >> In your opinion, was this assignment, or any one of the three problems
145 >> in it, too easy or too hard?  Did it take too long or too little time?
146
147 >> Did you find that working on a particular part of the assignment gave
148 >> you greater insight into some aspect of OS design?
149
150 >> Is there some particular fact or hint we should give students in
151 >> future quarters to help them solve the problems?  Conversely, did you
152 >> find any of our guidance to be misleading?
153
154 >> Do you have any suggestions for the TAs to more effectively assist
155 >> students, either for future quarters or the remaining projects?
156
157 >> Any other comments?