CS170 Lab 3 (pipe) -- Scoring Criteria

Here is the scoring criteria for lab 3, based on 13 questions, together amounting to 100 points. For questions 2-10 the score depended on whether the turned-in software was able to correctly execute a test. Each test was attemped with 4 builds of the turned-in software:

  1. testpipe executable was built using the turned-in rw_threads.c and the "official" version of sim_pipe.c.
  2. testpipe executable was built using the turned-in sim_pipe.c and the "official" version of rw_threads.c.
  3. testpipe executable was built using the turned-in code exclusively.
  4. testpipe executable was built using the turned-in code compiled with the DEBUG flag enabled and the "official" version of testpipe.c.

If all four builds passed, the full score of 8 points was given. If at least one build succeded, 5 points were given. (Consistent failure with either of the first two builds indicates that software was not written according to specification, with functionality properly divided between the implementation of pipes and the users of pipes.) If all builds failed the test, the score for that question is 0.

Admittedly, with this approach to scoring, one may lose points for the same bug in more than one question. The virtue of this approach is consistency in scoring across everyone's solutions. (Tracking down the ultimate cause of every bug and deciding on its penalty is fraught with danger.) Furthermore, we were generous with partial credit for solutions that contained non-deterministic bugs: if the same code worked with the same input at least once in four executions, more than half of the points were earned.

  1. [5] Where there warnings during compilation? We expect no warnings during compilation with default flags. It is a good idea to have no warnings even with -Wall flag.

  2. [5] How readable is the code? Meaningful variable names and helpful comments improve readability. Logical, simple structuring helps, too.

  3. [10] What was the quality of the code? Points will be docked for unused variables, illogical organization of code, for grossly inefficient use of memory, and for significant unnecessary code.

  4. [8] The write-up.

  5. [8] ./testpipe 1 1 1 1 1: one reader, one writer, byte-sized buffer, byte-at-a-time, one byte to send
  6. [8] ./testpipe 1 1 1 1 4: ...now 4 bytes to send
  7. [8] ./testpipe 1 2 1 2 4: ...now 2 writers, 2 at-a-time
  8. [8] ./testpipe 2 2 1 2 4: ...now 2 readers
  9. [8] ./testpipe 20 20 1 2 4: ...now 20 readers, 20 writers
  10. [8] ./testpipe 20 20 10 2 4: ...now a 10-byte buffer
  11. [8] ./testpipe 20 20 10 2 40: ...now 40 bytes to send
  12. [8] ./testpipe 20 20 10 20 40: ...now a 20-byte queue size
  13. [8] ./testpipe 4 4 100 20 40000: ...now fewer participants and more data