From f53494c28e362fb7752bbc83417b9ba47cff0bf5 Mon Sep 17 00:00:00 2001 From: rsc Date: Wed, 3 Sep 2008 04:50:04 +0000 Subject: DO NOT MAIL: xv6 web pages --- web/xv6-lock.html | 100 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 web/xv6-lock.html (limited to 'web/xv6-lock.html') diff --git a/web/xv6-lock.html b/web/xv6-lock.html new file mode 100644 index 0000000..887022a --- /dev/null +++ b/web/xv6-lock.html @@ -0,0 +1,100 @@ +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