From: Ben Pfaff Date: Mon, 27 Feb 2006 03:06:12 +0000 (+0000) Subject: More TODO items. X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=3389cbb515f92b56550c41b1ca0bda9d4a6fbf9e;p=pintos-anon More TODO items. --- diff --git a/TODO b/TODO index 9143cc7..85bd51a 100644 --- a/TODO +++ b/TODO @@ -1,5 +1,53 @@ -*- text -*- +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 +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" Subject: set_priority & donation - a TODO item To: "Ben Pfaff"