X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=doc%2Fthreads.texi;h=33600393977ff6b6f743f4124875eb00be91acd6;hb=6ad017d81335169c4048d08126c3848e445b8e04;hp=0b6bd701ff70acb6859c264959506acf8b14ae9a;hpb=bf077c029772a067944ef777b3b6873bb4f2b9e9;p=pintos-anon diff --git a/doc/threads.texi b/doc/threads.texi index 0b6bd70..3360039 100644 --- a/doc/threads.texi +++ b/doc/threads.texi @@ -157,9 +157,9 @@ the kernel. Basic interrupt handling and functions for turning interrupts on and off. -@item intr-stubs.pl +@item intr-stubs.S @itemx intr-stubs.h -A Perl program that outputs assembly for low-level interrupt handling. +Assembly code for low-level interrupt handling. @item synch.c @itemx synch.h @@ -380,11 +380,36 @@ Problems 1-3 and 1-4 won't be needed for later projects. @end itemize @item -Problem 1-4 (MLFQS) builds on the features you -implement in Problem 1-3. To avoid unnecessary code duplication, it -would be a good idea to divide up the work among your team members -such that you have Problem 1-3 fully working before you begin to tackle -Problem 1-4. +Problem 1-4 (MLFQS) builds on the features you implement in Problem +1-3. You should have Problem 1-3 fully working before you begin to +tackle Problem 1-4. + +@item +In the past, many groups divided the assignment into pieces, then each +group member worked on his or her piece until just before the +deadline, at which time the group reconvened to combine their code and +submit. @strong{This is a bad idea. We do not recommend this +approach.} Groups that do this often find that two changes conflict +with each other, requiring lots of last-minute debugging. Some groups +who have done this have turned in code that did not even successfully +boot. + +Instead, we recommend integrating your team's changes early and often, +using a source code control system such as CVS (@pxref{CVS}) or a +group collaboration site such as SourceForge (@pxref{SourceForge}). +This is less likely to produce surprises, because everyone can see +everyone else's code as it is written, instead of just when it is +finished. These systems also make it possible to review changes and, +when a change introduces a bug, drop back to working versions of code. + +@item +You should expect to run into bugs that you simply don't understand +while working on this and subsequent projects. When you do, go back +and reread the appendix on debugging tools, which is filled with +useful debugging tips that should help you to get back up to speed +(@pxref{Debugging Tools}). Be sure to read the section on backtraces +(@pxref{Backtraces}), which will help you to get the most out of every +kernel panic or assertion failure. @end itemize @node Problem 1-1 Alarm Clock @@ -462,7 +487,10 @@ exited at the time of the later joins. Thus, joins on T after the first should return immediately. Calling @func{thread_join} on an thread that is not the caller's -child should cause the caller to return immediately. +child should cause the caller to return immediately. For this purpose, +children are not inherited, that is, if @var{A} has child @var{B} and +@var{B} has child @var{C}, then @var{A} always returns immediately +should it try to join @var{C}, even if @var{B} is dead. Consider all the ways a join can occur: nested joins (@var{A} joins @var{B}, then @var{B} joins @var{C}), multiple joins (@var{A} joins @@ -470,15 +498,10 @@ Consider all the ways a join can occur: nested joins (@var{A} joins if @func{thread_join} is called on a thread that has not yet been scheduled for the first time? You should handle all of these cases. Write test code that demonstrates the cases your join works for. -Don't overdo the output volume, please! Be careful to program this function correctly. You will need its functionality for project 2. -Once you've implemented @func{thread_join}, define -@code{THREAD_JOIN_IMPLEMENTED} in @file{constants.h}. -@xref{Conditional Compilation}, for more information. - @node Problem 1-3 Priority Scheduling @section Problem 1-3: Priority Scheduling @@ -502,7 +525,9 @@ than the currently running thread, the current thread should immediately yield the processor to the new thread. Similarly, when threads are waiting for a lock, semaphore or condition variable, the highest priority waiting thread should be woken up first. A thread -may set its priority at any time. +may raise or lower its own priority at any time, but lowering its +priority such that it no longer has the highest priority must cause it +to immediately yield the CPU. One issue with priority scheduling is ``priority inversion'': if a high priority thread needs to wait for a low priority thread (for @@ -530,10 +555,6 @@ implement this fix for semaphores, condition variables, or joins, although you are welcome to do so. However, you do need to implement priority scheduling in all cases. -You may assume a static priority for priority donation, that is, it is -not necessary to ``re-donate'' a thread's priority if it changes -(although you are free to do so). - @node Problem 1-4 Advanced Scheduler @section Problem 1-4: Advanced Scheduler @@ -709,7 +730,9 @@ Make the timer tick more slowly by decreasing @code{TIMER_FREQ} in The former two changes are only desirable for testing problem 1-1 and possibly 1-3. You should revert them before working on other parts -of the project or turn in the project. +of the project or turn in the project. We will test problem 1-1 with +@code{TIME_SLICE} set to 100 and @code{TIMER_FREQ} set to 19, but we +will leave them at their defaults for all the other problems. @item @b{Should @file{p1-1.c} be expected to work with the MLFQS turned on?}