From 34980381bd75ce28ffea2113559aefa1b02c64f0 Mon Sep 17 00:00:00 2001 From: Frans Kaashoek Date: Mon, 29 Jul 2019 15:49:47 -0400 Subject: [PATCH] checkpoint --- labs/lock.html | 45 ++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 40 insertions(+), 5 deletions(-) diff --git a/labs/lock.html b/labs/lock.html index fe2da45..b43a51b 100644 --- a/labs/lock.html +++ b/labs/lock.html @@ -84,12 +84,47 @@ workloads.

Lock-free bcache lookup

-

Modify bget so that succesful lookups don't need to - acquire bcache.lock. The challenge is - concurrent brelse, which modify the list that bget - traverses. (Hint: there is no need for bget to use the - list.) + +

Several processes reading different files repeatedly will + bottleneck in the buffer cache, bcache, in bio.c. Replace the + acquire in bget with +

+    while(!tryacquire(&bcache.lock)) {
+      printf("!");
+    }
+  
+ + and run test0 from bcachetest and you will see "!"s. + +

Modify bget so that a lookup for a buffer that is in the + bcache doesn't need to acquire bcache.lock. This more + tricky than the kalloc assignment, because bcache buffers are truly + shared among processes. You must maintain the invariant that a + buffer is only once in memory. + +

There are several races that bcache.lock protects +against, including: +

+ +

A challenge is testing whether you code is still correct. One way + to do is to artificially delay certain operations + using sleepticks. + +

Here are some hints: +