ilo-pona/xv6-65oo2
1
0
Fork 0
Code Issues Pull requests Packages Projects Releases Activity

x

Browse source
This commit is contained in:
Frans Kaashoek 2019-07-30 13:07:17 -04:00
parent 848d1906e8
commit 9c4f62e8e3
1 changed files with 16 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
labs/lock.html
View file

@ -98,7 +98,7 @@ workloads.
and run test0 from bcachetest and you will see "!"s.
<p>Modify <tt>bget</tt> so that a lookup for a buffer that is in the
bcache doesn't need to acquire <tt>bcache.lock</tt>. This more
bcache doesn't need to acquire <tt>bcache.lock</tt>. This is 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.
@ -121,8 +121,13 @@ against, including:
<p>Here are some hints:
<ul>
<li>Read the description of buffer cache in the xv6 book (Section 7.2).
<li>Use a simple design: i.e., don't design a lock-free implementation.
<li>Use a simple hash table with locks per bucket
<li>Use a simple hash table with locks per bucket.
<li>Searching in hash table for a buffer and allocating an entry
for that buffer when the buffer is not found must be atomic.
<li>It is fine to acquire <tt>bcache.lock</tt> in <tt>brelse</tt>
to update the LRU/MRU list.
</ul>
<p>Check that your implementation has less contention
@ -130,5 +135,14 @@ against, including:
<p>Make sure your implementation passes bcachetest and usertests.
<p>Optional:
<ul>
<li>make the buffer cache more scalable (e.g., avoid taking
out <tt>bcache.lock</tt> on <tt>brelse</tt>).
<li>make lookup lock-free (Hint: use gcc's <tt>__sync_*</tt>
functions.) How do you convince yourself that your implementation is correct?
</ul>
</body>
</html>