Fix wrong explanation of sleeping in an interrupt handler.

Thanks to Godmar Back for reporting this bug.

diff --git a/TODO b/TODO
index 45b06ce068a72522a5acfd87cca5ec3f99304832..258e2fa8764ad80ceab3ef35c9a75998ab474970 100644 (file)
--- a/TODO
+++ b/TODO
@@ -103,38 +103,6 @@ I actually tested it and it's hard to pass with the current ips setting.
 The bounds on how quickly a thread would need to be able to return after
 sleep appear too tight.  Need another idea.
 
-From: "Godmar Back" <godmar@gmail.com>
-Subject: thread_yield in irq handler
-To: "Ben Pfaff" <blp@cs.stanford.edu>
-Date: Wed, 22 Feb 2006 22:18:50 -0500
-
-Ben,
-
-you write in your Tour of Pintos:
-
-"Second, an interrupt handler must not call any function that can
-sleep, which rules out thread_yield(), lock_acquire(), and many
-others. This is because external interrupts use space on the stack of
-the kernel thread that was running at the time the interrupt occurred.
-If the interrupt handler tried to sleep and that thread resumed, then
-the two uses of the single stack would interfere, which cannot be
-allowed."
-
-Is the last sentence really true?
-
-I thought the reason that you couldn't sleep is that you would put
-effectively a random thread/process to sleep, but I don't think it
-would cause problems with the kernel stack.  After all, it doesn't
-cause this problem if you call thread_yield at the end of
-intr_handler(), so why would it cause this problem earlier.
-
-As for thread_yield(), my understanding is that the reason it's called
-at the end is to ensure it's done after the interrupt is acknowledged,
-which you can't do until the end because Pintos doesn't handle nested
-interrupts.
-
- - Godmar
-
 From: "Godmar Back" <godmar@gmail.com>
 
 For reasons I don't currently understand, some of our students seem

diff --git a/doc/tour.texi b/doc/tour.texi
index f4760ec1ffd5a4cd76a2d1830814ead39e5f1a2c..c1371cfde5760df3df4129a4f5eec6b0c4d3e66e 100644 (file)
--- a/doc/tour.texi
+++ b/doc/tour.texi
@@ -1093,9 +1093,9 @@ Second, an interrupt handler must not call any function that can
 sleep, which rules out @func{thread_yield}, @func{lock_acquire}, and
 many others.  This is because external interrupts use space on the
 stack of the kernel thread that was running at the time the interrupt
-occurred.  If the interrupt handler tried to sleep and that thread
-resumed, then the two uses of the single stack would interfere, which
-cannot be allowed.
+occurred.  If the interrupt handler slept, it would effectively put that
+thread to sleep too until the interrupt handler resumed control and
+returned.
 
 Because an external interrupt runs with interrupts disabled, it
 effectively monopolizes the machine and delays all other activities.