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
@node Tips
@section Tips
-There should be no busy-waiting in any of your solutions to this
-assignment.
-
-Do your best to resist the temptation to directly disable interrupts
-in your solution by calling @func{intr_disable} or
-@func{intr_set_level}, although you may find doing so to be useful
-while debugging. Instead, use semaphores, locks and condition
-variables to solve synchronization problems. Read the tour section on
-synchronization (@pxref{Synchronization}) or the comments in
-@file{threads/synch.h} if you're unsure what synchronization
-primitives may be used in what situations.
-
-Given some designs of some problems, there may be one or two instances
-in which it is appropriate to directly change the interrupt levels
-instead of relying on the given synchronization primitives. This must
-be justified in your @file{DESIGNDOC} file. If you're not sure you're
-justified, ask!
-
-While all parts of this assignment are required if you intend to earn
-full credit on this project, keep in mind that Problem 1-2 (Join) will
-be needed for future assignments, so you'll want to get this one
-right. We don't give out solutions, so you're stuck with your Join
-code for the whole quarter. Problem 1-1 (Alarm Clock) could be very
-handy, but not strictly required in the future. The upshot of all
-this is that you should focus heavily on making sure that your
-implementation of @func{thread_join} works correctly, since if it's
-broken, you will need to fix it for future assignments. The other
-parts can be turned off in the future if you find you can't make them
-work quite right.
-
-Also keep in mind that Problem 1-4 (the MLFQS) builds on the features you
-implement in Problem 1-3, so 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.
+@itemize @bullet
+@item
+There should be no busy waiting in any of your solutions to this
+assignment. We consider a tight loop that calls @func{thread_yield}
+to be one form of busy waiting.
+
+@item
+Proper synchronization is an important part of the solutions to these
+problems. It is tempting to synchronize all your code by turning off
+interrupts with @func{intr_disable} or @func{intr_set_level}, because
+this eliminates concurrency and thus the possibility for race
+conditions, but @strong{don't}. Instead, use semaphores, locks, and
+condition variables to solve the bulk of your synchronization
+problems. Read the tour section on synchronization
+(@pxref{Synchronization}) or the comments in @file{threads/synch.c} if
+you're unsure what synchronization primitives may be used in what
+situations.
+
+You might run into a few situations where interrupt disabling is the
+best way to handle synchronization. If so, you need to explain your
+rationale in your design documents. If you're unsure whether a given
+situation justifies disabling interrupts, talk to the TAs, who can
+help you decide on the right thing to do.
+
+Disabling interrupts can be useful for debugging, if you want to make
+sure that a section of code is not interrupted. You should remove
+debugging code before turning in your project.
+
+@item
+All parts of this assignment are required if you intend to earn full
+credit on this project. However, some will be more important in
+future projects:
+
+@itemize @minus
+@item
+Problem 1-1 (Alarm Clock) could be handy for later projects, but it is
+not strictly required.
+
+@item
+Problem 1-2 (Join) will be needed for future projects. We don't give
+out solutions, so to avoid extra work later you should make sure that
+your implementation of @func{thread_join} works correctly.
+
+@item
+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. 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
@section Problem 1-1: Alarm Clock
@func{thread_join}'s parameter type because a thread pointer is not
unique over time. That is, when a thread dies, its memory may be,
whether immediately or much later, reused for another thread. If
-thread A over time had two children B and C that were stored at the
-same address, then @code{thread_join(@var{B})} and
+thread @var{A} over time had two children @var{B} and @var{C} that
+were stored at the same address, then @code{thread_join(@var{B})} and
@code{thread_join(@var{C})} would be ambiguous. Introducing a thread
id or @dfn{tid}, represented by type @code{tid_t}, that is
intentionally unique over time solves the problem. The provided code
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
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
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
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
Therefore, in general, setting the interrupt level should be used
sparingly. Also, any synchronization problem can be easily solved by
turning interrupts off, since while interrupts are off, there is no
-concurrency, so there's no possibility for race condition.
+concurrency, so there's no possibility for race conditions.
To make sure you understand concurrency well, we are discouraging you
from taking this shortcut at all in your solution. If you are unable
projects / pintos-anon / blobdiff