More TODO items.

diff --git a/TODO b/TODO
index 9143cc7fdf970c7816ed81c0da6c8b4763539da6..85bd51a0a73484bc5c9940c88fb705bfbbec40c6 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,5 +1,53 @@
 -*- text -*-
 
+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
+hesitant to include each thread in a second "all-threads" list and are
+looking for ways to implement the advanced scheduler without one.
+
+Currently, I believe, all tests for the mlfqs are such that all
+threads are either ready or sleeping in timer_sleep(). This allows for
+an incorrect implementation in which recent-cpu and priorities are
+updated only for those threads that are on the alarm list or the ready
+list.
+
+The todo item would be a test where a thread is blocked on a
+semaphore, lock or condition variable and have its recent_cpu decay to
+zero, and check that it's scheduled right after the unlock/up/signal.
+
 From: "Godmar Back" <godmar@gmail.com>
 Subject: set_priority & donation - a TODO item
 To: "Ben Pfaff" <blp@cs.stanford.edu>