Tips for NACHOS Assignment 1

All of assignment 1 can be done inside of the directory code/threads. Here are some hints on how to get started and how to proceed.

Big tip #1: If you don't have time to do it properly the first time when will you find time to fix it.

Big tip #2: Don't code until you understand what you are going to do and how to do it.

Big tip #3 Read and understand the sample solutions handed out on the first day of class (these are not available anywhere in the web pages). These should help you to design and implement Reader / Writer locks.

A Possible Strategy

• Read the Nachos paper.
  
• Have a look at the the Nachos Roadmap document. In particular the section on Nachos Threads and the section Experience with Nachos Assignments.
  
• Looking at and understand the Semphores class (synch.h).
  
• Start by building locks. You'll have to add some data members to the class Lock in the file synch.h and you have to implement the Lock function members described (the skeltons are in synch.cc and have to be filled in).
  
• You'll probably want to build Barriers early on as well as it will be useful when testing your implementation of locks (i.e., you can ensure that all threads finish before the parent finished - if you find that useful). Again you'll find the definition of the Barrier class in synch.h and skeltons for the function members in synch.cc - your job is to fill in the details.
  
• Test the locks by implementing a simple program or two. For example, create multiple threads half of which increment a counter, the other half of which decrement a counter. When all are finished the count should be zero (assuming it's initialized to zero.
  
• Implement the Condition class. (again by modifying synch.h and synch.cc in a similar way as was done for the Lock class).
  
• Implement the Reader/Writer Lock class called RWLock (again by modifying synch.h and synch.cc).
  
• Test the Lock, Barrier, Condition and RWLock classes either before doing the other parts of assignment one or while you are completing solutions (although if you will probably find it easier if you are convinced that you've implemented your synchronization classes correctly first).
  
• The RWLock class is one that will be useful in assignment four. Therefore, it may not be useful when providing solutions to the other assigned problems until assignment 4.

Things to Remember (Gotcha's)

• Remember to use gmake (gnu-make).
• When adding files to the makefiles add them to code/Makefile.common then do:

  % gmake depend
  

  to get the dependencies set up.
• Learn to use the debugging options to Nachos.
• Add more debugging statements and options for debugging different portions of the system.
• Learn and use a debugger (e.g., gdb).
• Without a correct implementation of Locks and Condition variables the rest of the operating system will not function correctly.
• Chpt 9 Bacon: WARNING : terminology Wait/Signal is confusing when taken in context of Condition variables and the assignments.
  
  Birrell paper: good sections on Condition Variables, Mutual exclusion and synchronization
• IMPORTANT: Don't change anything in the code/machine directory. Doing so is considered to be equivalent to modifying the hardware which in the case of most Operating System designers and builders is simply not possible.
  
• IMPORTANT: Time only advances in Nachos when: interrupts are re-enabled, a user instruction is executed, there is nothing in the ready queue. Since no user programs are being executed in this assignment and if you have multiple threads executing it's quite likely that time will only advance when interrupts are re-enabled.
  
• Remember to really test your implementation you need to ensure that the different threads executing can actually get interrupted (i.e., each thread doesn't take turns running to completion). Don't disable and enable interrupts in your test programs but be sure to call functions that you know do.
  
• Remember to run multiple test using the -rs option. If you don't you haven't shown that your solution works.

Handing in the Assignment

Reread the Project Mechanics Document. Please divide your assignment into the following 4 sections.

• Title Page: Be sure to include the course name, your group members, student id's, etc.
  
• Design: This is the main documentation for your project. Briefly and clearly describe your design decisions. After reading this I should know what to expect when reading your code.
  IMPORTANT: grammar, spelling, and general writing skills are very important and will count significantly in your grade.
  
• Implementation: This is the actual code for your assigment. (Not including the source for the test programs.) The code should be well formated, commented clearly and generally a work of beauty.
  YOU MUST use the coding standards (style) already in place no matter how much you believe that you have a better style. Virtually any place you work will have their own coding standards and you'll never be completely happy with them anywhere. Learn to tow the line.
  
• Testing: This section should include the source for your test programs. In the first assignment these are any programs/test you wrote to test out the implementation of the synchronization classes as well as solutions to the other portions of the assignment. In subsequent assignments the test programs will largely consist of user programs written to test the operating system. Besides including the source you must also include sample runs of these tests
  Remember that your aim is to convince me (or your boss) as quickly as possible that your implementation is solid. If you were working for a company you might have a meeting with the boss (or group of co-workers) where you get 10 minutes to make your case - think of that while deciding what and how to test.
  
  REMEMBER: Demonstrating what doesn't work is just as important as demonstrating what does. If I find things that don't work and you haven't indicated that they do not work you will be graded down. (The assumption is that you didn't realize that it didn't work when you should have - as a result the project suffers.)
  

• When printing and handing in the code for the assignment please show the .h file first followed immediately by the corresponding .cc file. ( PLEASE: Do not list all of the .h files followed by all of the .cc files.)

• Please use enscript to hand in your code. Also be sure that both before and after you print your program out that it is formated nicely. Just because it looks good on the screen with your editor and your tab settings doesn't mean that it will look good when printed. It must look good when printed because that's what will be graded and style does count in your grade.