diff options
| author | Frans Kaashoek <kaashoek@mit.edu> | 2019-07-30 10:01:22 -0400 | 
|---|---|---|
| committer | Frans Kaashoek <kaashoek@mit.edu> | 2019-07-30 10:01:22 -0400 | 
| commit | 87183da13d80555fde253823108be12667246079 (patch) | |
| tree | 5375d1e8206dbef79a3e2091ec1af9561b1c52de | |
| parent | f37a3e396454268074f48517e3773f099846d0e3 (diff) | |
| download | xv6-labs-87183da13d80555fde253823108be12667246079.tar.gz xv6-labs-87183da13d80555fde253823108be12667246079.tar.bz2 xv6-labs-87183da13d80555fde253823108be12667246079.zip | |
An easier version of bcache assignment
| -rw-r--r-- | labs/lock.html | 18 | 
1 files changed, 11 insertions, 7 deletions
| 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> | 
