Message 39

Assignment #1 graded.

Message-ID: <kvhukPS00UjKRCPUtW@andrew.cmu.edu>
Date: Sun, 30 Sep 2001 19:34:51 -0400 (EDT)
From: Leejay Wu <lw2j+@andrew.cmu.edu>
Content-Type: text/plain
If-Type-Unsupported: alter
To: Andrew BBoard Account <bb+academic.cs.15-721@andrew.cmu.edu>
Subject: Assignment #1 graded.
Cc: Anastassia.Ailamaki@cs.cmu.edu

- Your assignments should all have been graded.  Check your
 
  handin/<AndrewID>/BufMgr
  
  directories; if you got a grade, it should, along with comments,
  be in a file called GRADING, with a format like

    60/100
    
    Comments:  [lw2j]

    - Bleah bleah bleah.  Bleah, bleah and yet more bleah.

    - You shouldn't be poking bits there and probing
      random memory addresses; this has a propensity to
      make certain common, but badly-designed, hardware 
      collapse into a miniature black hole and destroy the 
      host planet, resulting in severe data loss.  [-40]

- All numbers relating to grades -- deductions, say -- are 
  explicitly mentioned.  For instance, if I mentioned that a linear
  scan for removing a frame from the middle of the free list could
  be avoided, I still didn't deduct points for it and there's 
  no corresponding [-x].

- If you don't have such a file, you won't be receiving a grade.
  If you're missing it, and you handed in code, tell me.  Likewise,
  if your partner handed it in, and you're missing a GRADING file,
  tell me.  Whenver I noticed a reference to partners, it's 
  mentioned in the GRADING file itself.

- How they were graded:

  - They were automatically compiled in a BUILD directory underneath
    your BufMgr directory, with appropriate symlinks made.  The
    outputs of 'make' and './buftest' were logged to make.log and
    buftest.log, respectively.

  - If the code didn't build, I created a copy of your buf.C and
    fiddled with it (adding #ifdef TA_HACK blocks) to try to get
    it to build.

  - I then read through the logs, your header and .C file, looking
    for various nastiness.

  - In general, performance issues were not deducted for, with the
    exception of doing a linear scan to simply find out whether or
    not a page is in the buffers.  For instance, if you wrote to
    disk after an unpin drove the pin count to 0, it's inefficient
    and I commented about it (think:  hot spots), but I didn't
    deduct for it.  We might be more explicit about performance
    next time, but...
 
  - The problems that DID result in deductions were generally
    corruption / data loss / resource leakage issues.

    * Doing a linear scan simply to check whether or not a page
      is buffered:  [-5].  This might be a VERY frequent operation,
      since pinPage() needs to do it, and the ratio of database 
      pages in buffer to pages not in buffer could be very, very
      low, meaninig that needing to do a full linear scan is 
      going to hurt (in a real system with a real amount of RAM
      for buffers).  This is the one performance issue for which
      I deducted points, methinks.

    * Memory leaks, usually due to a lazy destructor but sometimes
      due to forgetting about removed linked list nodes -- [-5].
      
    * Page leaks, such as not deallocating a page when necessary --
      say, a problematic freePage(), or if the pin fails in 
      newPage() -- [-7]. 

    * Flushing a pinned page is dangerous.  I allowed solutions
      which flushed a singly-pinned page without penalty, using 
      the same not particularly safe rationale as freePage();
      but flushing a doubly-or-more-pinned page is dangerous.

      After all,
      - That could well indicate two separate threads using the
        same frame.
      - They've both got pointers to the frame itself.
      - They might well think that their pointers are still
        valid, and write to them...
      - ...corrupting whatever page replaced the flushed one,
        if any.  And since it's a write to a valid chunk of
        memory, it might go undetected for a rather long time.

      Due to potential severity, [-10].


    * unpinPage() should OR the dirty bit with the previous one,
      not simply use whatever the client gives you.  Say...

      - Transaction 1 begins.
      - It pins page X, writes to it, and unpins it.
        Page X is now labeled as dirty.
      - Transaction 1 ends.

      :: a very short time later, before Page X gets flushed to
         disk :: 

      - Transaction 2 begins.
      - It pins page X, reads from it, and unpins it -- with 
        dirty=false, which makes since as it's only a reader.
      - Page X is now labeled as clean, if one erroneously uses
        whatever the client tells it rather than OR-ing it.
      
      If Page X is then removed from the buffer before a third
      transaction marks it as dirty again, the writes from
      Transaction 1 will be lost.  Again, this is rather severe,
      so I considered this a [-10].


Oh, and the key should be readable now, in

 <class_root>/mini_hwk/assign/BufMgr/key

It ain't pretty, but it's serviceable.  FWIW, it's basically
identical to Minibase's own code, except for lacking concurrency
control #ifdef's; having LRU replacement; and some very minor
code cleanups.
-- 
|   lw2j@cs.cmu.edu        | #include <0.0648g NaCl>     |              
|--------------------------|-----------------------------|  
|   #include <stddiscl.h>  | Spam returned to postmaster |