From: Ben Pfaff Date: Sun, 9 Apr 2006 20:01:51 +0000 (+0000) Subject: Fix wrong explanation of sleeping in an interrupt handler. X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=53c72bbcd172e54412bbe796e0032136066061f6;p=pintos-anon Fix wrong explanation of sleeping in an interrupt handler. Thanks to Godmar Back for reporting this bug. --- diff --git a/TODO b/TODO index 45b06ce..258e2fa 100644 --- 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" -Subject: thread_yield in irq handler -To: "Ben Pfaff" -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" For reasons I don't currently understand, some of our students seem diff --git a/doc/tour.texi b/doc/tour.texi index f4760ec..c1371cf 100644 --- 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.