From 01a6c054d548d9fff8bbdfac4d3f3de4ae8677a1 Mon Sep 17 00:00:00 2001 From: Austin Clements Date: Wed, 7 Sep 2011 11:49:14 -0400 Subject: Remove web directory; all cruft or moved to 6.828 repo --- web/xv6-lock.html | 100 ------------------------------------------------------ 1 file changed, 100 deletions(-) delete mode 100644 web/xv6-lock.html (limited to 'web/xv6-lock.html') diff --git a/web/xv6-lock.html b/web/xv6-lock.html deleted file mode 100644 index 887022a..0000000 --- a/web/xv6-lock.html +++ /dev/null @@ -1,100 +0,0 @@ -Homework: Locking - - - - - -

Homework: Locking

- - -

-Read: spinlock.c - -

-Hand-In Procedure -

-You are to turn in this homework at the beginning of lecture. Please -write up your answers to the exercises below and hand them in to a -6.828 staff member at the beginning of lecture. -

- -Assignment: -In this assignment we will explore some of the interaction -between interrupts and locking. -

- -Make sure you understand what would happen if the kernel executed -the following code snippet: -

-  struct spinlock lk;
-  initlock(&lk, "test lock");
-  acquire(&lk);
-  acquire(&lk);
-
-(Feel free to use Bochs to find out. acquire is in spinlock.c.) -

- -An acquire ensures interrupts are off -on the local processor using cli, -and interrupts remain off until the release -of the last lock held by that processor -(at which point they are enabled using sti). -

- -Let's see what happens if we turn on interrupts while -holding the ide lock. -In ide_rw in ide.c, add a call -to sti() after the acquire(). -Rebuild the kernel and boot it in Bochs. -Chances are the kernel will panic soon after boot; try booting Bochs a few times -if it doesn't. -

- -Turn in: explain in a few sentences why the kernel panicked. -You may find it useful to look up the stack trace -(the sequence of %eip values printed by panic) -in the kernel.asm listing. -

- -Remove the sti() you added, -rebuild the kernel, and make sure it works again. -

- -Now let's see what happens if we turn on interrupts -while holding the kalloc_lock. -In kalloc() in kalloc.c, add -a call to sti() after the call to acquire(). -You will also need to add -#include "x86.h" at the top of the file after -the other #include lines. -Rebuild the kernel and boot it in Bochs. -It will not panic. -

- -Turn in: explain in a few sentences why the kernel didn't panic. -What is different about kalloc_lock -as compared to ide_lock? -

-You do not need to understand anything about the details of the IDE hardware -to answer this question, but you may find it helpful to look -at which functions acquire each lock, and then at when those -functions get called. -

- -(There is a very small but non-zero chance that the kernel will panic -with the extra sti() in kalloc. -If the kernel does panic, make doubly sure that -you removed the sti() call from -ide_rw. If it continues to panic and the -only extra sti() is in bio.c, -then mail 6.828-staff@pdos.csail.mit.edu -and think about buying a lottery ticket.) -

- -Turn in: Why does release() clear -lock->pcs[0] and lock->cpu -before clearing lock->locked? -Why not wait until after? - - - -- cgit v1.2.3