From 87183da13d80555fde253823108be12667246079 Mon Sep 17 00:00:00 2001
From: Frans Kaashoek <kaashoek@mit.edu>
Date: Tue, 30 Jul 2019 10:01:22 -0400
Subject: An easier version of bcache assignment

---
 labs/lock.html | 18 +++++++++++-------
 1 file changed, 11 insertions(+), 7 deletions(-)

(limited to 'labs')

diff --git a/labs/lock.html b/labs/lock.html
index b43a51b..a93eb3a 100644
--- a/labs/lock.html
+++ b/labs/lock.html
@@ -82,7 +82,7 @@ workloads.
 
 <p>Run usertests to see if you don't break anything.
 
-<h2>Lock-free bcache lookup</h2>
+<h2>More scalabale bcache lookup</h2>
 
 
 <p>Several processes reading different files repeatedly will
@@ -116,15 +116,19 @@ against, including:
 
 <p>A challenge is testing whether you code is still correct.  One way
   to do is to artificially delay certain operations
-  using <tt>sleepticks</tt>.
+  using <tt>sleepticks</tt>.  <tt>test1</tt> trashes the buffer cache
+  and exercises more code paths.
 
 <p>Here are some hints:
   <ul>
-    <li> Use an atomic increment instruction for incrementing and
-      decrementing <tt>b->ref</tt> (see <tt>__sync_fetch_and_add() and
-	related primitives</tt>)
-    <li>Don't walk the <tt>bcache.head</tt> list to find a buffer
+    <li>Use a simple design: i.e., don't design a lock-free implementation.
+    <li>Use a simple hash table with locks per bucket
   </ul>
-  
+
+<p>Check that your implementation has less contention
+  on <tt>test0</tt>
+
+<p>Make sure your implementation passes bcachetest and usertests.
+
 </body>
 </html>
-- 
cgit v1.2.3