Add another test that checks priority scheduling in the case of

[pintos-anon] / TODO

diff --git a/TODO b/TODO
index 522847aa1dc88f2a95d36d3a0f193c13ec8353c8..53a7060081310488bf1d7f47e4722f2aba11f4cf 100644 (file)
--- a/TODO
+++ b/TODO
@@ -26,46 +26,6 @@ Add a system call "get_kernel_memory_information".  User programs
 could engage in a variety of activities and notice leaks by checking
 the kernel memory statistics.
 
----
-
-From: "Godmar Back" <godmar@gmail.com>
-Subject: priority donation tests
-To: "Ben Pfaff" <blp@cs.stanford.edu>
-Date: Fri, 3 Mar 2006 11:02:08 -0500
-
-Ben,
-
-it seems the priority donation tests are somewhat incomplete and allow
-incorrect implementations to pass with a perfect score.
-
-We are seeing the following wrong implementations pass all tests:
-
-- Implementations that assume locks are released in the opposite order
-in which they're acquired. The students implement this by
-popping/pushing on the donation list.
-
-- Implementations that assume that the priority of a thread waiting on
-a semaphore or condition variable cannot change between when the
-thread was blocked and when it is unblocked. The students implement
-this by doing an insert into an ordered list on block, rather than
-picking the maximum thread on unblock.
-
-Neither of these two cases is detected; do you currently check for
-these mistakes manually?
-
-I wrote a test that checks for the first case; it is here:
-http://people.cs.vt.edu/~gback/pintos/priority-donate-multiple-2.patch
-
-[...]
-
-I also wrote a test case for the second scenario:
-http://people.cs.vt.edu/~gback/pintos/priority-donate-sema.c
-http://people.cs.vt.edu/~gback/pintos/priority-donate-sema.ck
-
-I put the other tests up here:
-http://people.cs.vt.edu/~gback/pintos/priority-donate-multiple2.c
-http://people.cs.vt.edu/~gback/pintos/priority-donate-multiple2.ck
-
 From: "Godmar Back" <godmar@gmail.com>
 Subject: multiple threads waking up at same clock tick
 To: "Ben Pfaff" <blp@cs.stanford.edu>