6.033 Class Notes Errata
If you notice errors of any kind in the 6.033 class notes, ranging
from minor typos to major blunders, please report them by e-mail
to Saltzer@mit.edu and kaashoek@mit.edu.
|
|
|
April 14, 2006 |
Pages 9-49 to 9-56 (in Section C). The terminology of "winners" and "losers" on
these
pages was modified from last year, but the modification didn't get
completely propagated through the text. For details, see the
corrected version, which has change bars
in the margins. |
|
|
March 16, 2006 |
Page 7-58. The sentence right below the signature of
network_send() is missing words. It should be: "...select a network
protocol with which to send this_segment, and..." |
|
|
March 3, 2006 |
Figure 5-23: The implementation of yield is incorrect. It only
works for one processor. With more than one processor, two
processors may end up running the same thread, which is wrong! To
see how this could happen, consider 2 processors and 3 threads, and
the following sequence of events. Threads 0 and 1 run on processor
A and B, respectively. Next to run will be thread 2. When thread 1
yields, processor B will run thread 2. When thread 2 yields,
processor B will run thread 0. Now processors A and B are running
thread 0. The correct solution is to add a state variable for each
thread recording whether it is running or runnable, and to skip
running threads. Figure 5-24 is better, but also wrong (see next
errata).
|
|
|
March 3, 2006 |
Figure 5-24: There are two lines "ID <- (ID + 1) mod 7". The
second one should be deleted. Both figure 5-23 and 5-24 should
state the assumption that their correctness relies on the fact that
there are more threads than processors; otherwise, one of the extra
processors will search endlessly, keeping the threadtable locked,
thus preventing any other thread from yielding. Finally, when
entering yield, the processor should set the state of the thread it was
running to RUNNABLE (in the else clause), and the state of the newly
selected thread to RUNNING.
|
|
|
|