Make tests public. Rewrite most tests. Add tests.
[pintos-anon] / doc / threads.tmpl
diff --git a/doc/threads.tmpl b/doc/threads.tmpl
new file mode 100644 (file)
index 0000000..367baf4
--- /dev/null
@@ -0,0 +1,157 @@
+                       +--------------------+
+                       |        CS 140      |
+                       | PROJECT 1: THREADS |
+                       |   DESIGN DOCUMENT  |
+                       +--------------------+
+                                  
+---- GROUP ----
+
+>> Fill in the names and email addresses of your group members.
+
+FirstName LastName <email@domain.example>
+FirstName LastName <email@domain.example>
+FirstName LastName <email@domain.example>
+
+---- PRELIMINARIES ----
+
+>> If you have any preliminary comments on your submission, notes for the
+>> TAs, or extra credit, please give them here.
+
+>> Please cite any offline or online sources you consulted while
+>> preparing your submission, other than the Pintos documentation, course
+>> text, and lecture notes.
+
+                            ALARM CLOCK
+                            ===========
+
+---- DATA STRUCTURES ----
+
+>> Copy here the declaration of each new or changed `struct' or `struct'
+>> member, global or static variable, `typedef', or enumeration.
+>> Identify the purpose of each in 25 words or less.
+
+---- ALGORITHMS ----
+
+>> Briefly describe what happens in a call to thread_sleep(), including
+>> the effects of the timer interrupt handler.
+
+>> What steps are taken to minimize the amount of time spent in the timer
+>> interrupt handler?
+
+---- SYNCHRONIZATION ----
+
+>> How are race conditions avoided when multiple threads call
+>> thread_sleep() simultaneously?
+
+>> How are race conditions avoided when a timer interrupt occurs during a
+>> call to thread_sleep()?
+
+---- RATIONALE ----
+
+>> Why did you choose this design?  In what ways is it superior to
+>> another design you considered?
+
+                        PRIORITY SCHEDULING
+                        ===================
+
+---- DATA STRUCTURES ----
+
+>> Copy here the declaration of each new or changed `struct' or `struct'
+>> member, global or static variable, `typedef', or enumeration.
+>> Identify the purpose of each in 25 words or less.
+
+>> Explain the data structure used to track priority donation.  Use ASCII
+>> art to diagram a nested donation.
+
+---- ALGORITHMS ----
+
+>> How do you ensure that the highest priority thread waiting for a lock,
+>> semaphore, or condition variable wakes up first?
+
+>> Describe the sequence of events when a call to lock_acquire() causes a
+>> priority donation.  How is nested donation handled?
+
+>> Describe the sequence of events when lock_release() is called on a
+>> lock that a higher-priority thread is waiting for.
+
+---- SYNCHRONIZATION ----
+
+>> Describe a potential race in thread_set_priority() and explain how
+>> your implementation avoids it.  Can you use a lock to avoid this race?
+
+---- RATIONALE ----
+
+>> Why did you choose this design?  In what ways is it superior to
+>> another design you considered?
+
+                         ADVANCED SCHEDULER
+                         ==================
+
+---- DATA STRUCTURES ----
+
+>> Copy here the declaration of each new or changed `struct' or `struct'
+>> member, global or static variable, `typedef', or enumeration.
+>> Identify the purpose of each in 25 words or less.
+
+---- ALGORITHMS ----
+
+>> Suppose threads A, B, and C have nice values 0, 1, and 2.  Each has a
+>> recent_cpu value of 0.  Fill in the table below showing the scheduling
+>> decision and the priority and recent_cpu values for each thread after
+>> each given number of timer ticks:
+
+timer  recent_cpu    priority   thread
+ticks   A   B   C   A   B   C   to run
+-----  --  --  --  --  --  --   ------
+ 0
+ 4
+ 8
+12
+16
+20
+24
+28
+32
+36
+
+>> Did any ambiguities in the scheduler specification make values in the
+>> table uncertain?  If so, what rule did you use to resolve them?  Does
+>> this match the behavior of your scheduler?
+
+---- RATIONALE ----
+
+>> Critique your design, pointing out advantages and disadvantages in
+>> your design choices.  If you were to have extra time to work on this
+>> part of the project, how might you choose to refine or improve your
+>> design?
+
+>> The assignment explains arithmetic for fixed-point math in detail, but
+>> it leaves it open to you to implement it.  Why did you decide to
+>> implement it the way you did?  If you created an abstraction layer for
+>> fixed-point math, that is, an abstract data type and/or a set of
+>> functions or macros to manipulate fixed-point numbers, why did you do
+>> so?  If not, why not?
+
+                          SURVEY QUESTIONS
+                          ================
+
+Answering these questions is optional, but it will help us improve the
+course in future quarters.  Feel free to tell us anything you
+want--these questions are just to spur your thoughts.  You may also
+choose to respond anonymously in the course evaluations at the end of
+the quarter.
+
+>> In your opinion, was this assignment, or any one of the three problems
+>> in it, too easy or too hard?  Did it take too long or too little time?
+
+>> Did you find that working on a particular part of the assignment gave
+>> you greater insight into some aspect of OS design?
+
+>> Is there some particular fact or hint we should give students in
+>> future quarters to help them solve the problems?  Conversely, did you
+>> find any of our guidance to be misleading?
+
+>> Do you have any suggestions for the TAs to more effectively assist
+>> students, either for future quarters or the remaining projects?
+
+>> Any other comments?