-*- text -*-
-From: "Waqar Mohsin" <wmohsin@gmail.com>
-Subject: 3 questions about switch_threads() in switch.S
-To: blp@cs.stanford.edu, joshwise@stanford.edu
-Date: Fri, 3 Mar 2006 17:09:21 -0800
+* Bochs is not fully reproducible.
+
+Godmar says:
+
+- In Project 2, we're missing tests that pass arguments to system calls
+that span multiple pages, where some are mapped and some are not.
+An implementation that only checks the first page, rather than all pages
+that can be touched during a call to read()/write() passes all tests.
+
+- In Project 2, we're missing a test that would fail if they assumed
+that contiguous user-virtual addresses are laid out contiguously
+in memory. The loading code should ensure that non-contiguous
+physical pages are allocated for the data segment (at least.)
+
+- Need some tests that test that illegal accesses lead to process
+termination. I have written some, will add them. In P2, obviously,
+this would require that the students break this functionality since
+the page directory is initialized for them, still it would be good
+to have.
+
+- There does not appear to be a test that checks that they close all
+fd's on exit. Idea: add statistics & self-diagnostics code to palloc.c
+and malloc.c. Self-diagnostics code could be used for debugging.
+The statistics code would report how much kernel memory is free.
+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:
-QUESTION 1
-
-In the section
-
- # Save current stack pointer to old thread's stack, if any.
- movl SWITCH_CUR(%esp), %eax
- test %eax, %eax
- jz 1f
- movl %esp, (%eax,%edx,1)
-1:
+- 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.
- # Restore stack pointer from new thread's stack.
- movl SWITCH_NEXT(%esp), %ecx
- movl (%ecx,%edx,1), %esp
+- 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.
-why are we saving the current stack pointer only if the "cur" thread pointer
-is non-NULL ? Isn't it gauranteed to be non-NULL because switch_threads() is
-only called form schedule(), where we have
+Neither of these two cases is detected; do you currently check for
+these mistakes manually?
- struct thread *cur = running_thread ();
+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
-which should always be non-NULL (given the way kernel pool is laid out).
+[...]
+
+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>
+Date: Wed, 1 Mar 2006 08:14:47 -0500
+
+Greg Benson points out another potential TODO item for P1.
+
+----
+One thing I recall:
+
+The alarm tests do not test to see if multiple threads are woken up if
+their timers have expired. That is, students can write a solution
+that just wakes up the first thread on the sleep queue rather than
+check for additional threads. Of course, the next thread will be
+woken up on the next tick. Also, this might be hard to test.
+
+---
+Way to test this: (from Godmar Back)
+
+Thread A with high priority spins until 'ticks' changes, then calls to
+timer_sleep(X), Thread B with lower priority is then resumed, calls
+set_priority to make its priority equal to that of thread A, then
+calls timer_sleep(X), all of that before the next clock interrupt
+arrives.
+
+On wakeup, each thread records wake-up time and calls yield
+immediately, forcing the scheduler to switch to the other
+equal-priority thread. Both wake-up times must be the same (and match
+the planned wake-up time.)
+
+PS:
+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: "Waqar Mohsin" <wmohsin@gmail.com>
+Subject: 3 questions about switch_threads() in switch.S
+To: blp@cs.stanford.edu, joshwise@stanford.edu
+Date: Fri, 3 Mar 2006 17:09:21 -0800
QUESTION 2
* lock_acquire(), lock_release() don't need additional intr_dis/enable
calls, because the semaphore protects lock->holder.
+ [ Think this over: is this really true when priority donation is
+ implemented? intr_dis/enable prevents the race with thread_set_priority.
+ Leaving it there could help the students getting the correct synchronization
+ right.
+ ]
projects / pintos-anon / blobdiff