Hints and Implementation Details

1. One way to think of parts 3-6 is as one big part, with the goal being part 6. Parts 3-5 are simply there to develop the project in logical steps. (However, you are required to submit independent working versions of all parts.)
2. If you design/write your parts 3-6 well, then you'll likely only need to change certain sections of each one, as you ``upgrade'' it to become the next part. Pay careful attention to the numbers/sizes/counters, as some do change between parts.
3. For this project efficiency is not a real issue, so there is no need to implement time-saving features such as TLB's, hash tables, inverted tables etc. Doing linear searches through tables is perfectly acceptable.
4. When the project states that an action needs to get taken N% of the time, it means that a random number has to be chosen, and that action should occur if the random number is within N% of its possible range. For example, if it were stated that action Q needs to be taken 50% of the time, and action R the other 50%, then you could choose a random number 0 or 1, and do Q if the random number if 0, and R otherwise. If it is some number other than 50%, then choose a random number from a larger range, and take the appropriate action. So, for ranges 60%, 20%, 20%, you could choose a number from 0 to 99, and then check if it's 0-59, 60-79, and 80-99 for the respective actions.
5. See the man pages for more details about specific system or library calls and commands, such as: pthread_create(3T), nanosleep(3R), pthread_mutex_lock(3T), lrand48(3C), srand48(3C) etc.
6. Be sure that you set PTHREAD_SCOPE_SYSTEM on all your threads.
7. Be sure to always have your program wait (using pthread_join repeatedly as required) for all threads to complete. Remember that when the process exits (either by explicitly calling exit or by falling off the end of main) all threads die immediately.
8. In threaded programs, remember that you must protect accesses to shared data structures, or else they are liable to get corrupted. In designing your locking mechanisms, try to use as few locks as possible (as then it is then easier avoid deadlock) but with sufficient locks to allow for concurrency.
9. A good first check that you're doing the previous two points correctly, is that the last status message from the program should indicate that all memory is free. If that is not the case, then either all your threads are not completing, or you have some memory corruption due to bad locking, or else you have some other basic algorithm(s) incorrect.
10. In the threaded parts, the output from the various threads is likely to be interleaved on the screen. That is perfectly acceptable and expected--do not implement any output locking to prevent that from happening.
11. In the threaded programs, I recommend that you use cc or CC (rather than gcc or g++) as your compiler. And, be sure to pass the compiler the -mt flag, or else various bad stuff might happen!
12. Your program must be robust. If any of the calls fail, it should print error message and exit with appropriate error code. Always check for failure when invoking any system or library call especially calls to locking functions (such as pthread_mutex_lock). By convention, most UNIX calls return a value of NULL or negative one (-1) in case of an error (but always check the RETURN VALUES section of each man page for details), and you can use this information for a graceful exit. Use cerr, perror(3), or strerror(3) library routines to generate/print appropriate error messages.
13. There are some sample implementations of some of the Main Parts in ~milun/cs421/DEMOS/ on armstrong/gagarin/yeager/fork. Note that these are there to demonstrate the basics of what your projects should do. But they do not necessarily meet the project specifications exactly: they might be logging extra or insufficient information; they might have some parameters/counters set to different values than the project description, etc. In all cases that these demos differ from the project specification, the project specifications takes precedence.