Programming Assignment IV

Due on Friday, April 4, 2014 @ 11pm

100 points

This is a ThreadMentor programming assignment, and you can only use semaphores and locks. The use of any other system and/or synchronization primitives is unacceptable.

Party Room Problem

A landlord has a big apartment with a fantastic social room. Many students stay in this apartment. Since the neighbors frequently complained about party noise, the landlord came and checked his apartment frequently to ensure his fantastic social room is being used properly, and break up the party if there are too many students in the room.

Here is a list of rules:

The landlord is a thread with the following pattern. The landlord only checks the room m times and retires because he feels it is too tedious to handle this situation. After m iterations, he sends all students home, sells his apartment, and goes to Bahama for a long long vacation. 
for (i = 0; i < m; i++) {     // m is an input value
     Delay();                 // take some rest
     CheckRoom(...);          // check the social room
     Delay();                 // take some rest
}

CheckRoom() is a function for the landlord to check the room based on the above rules.

Each student is also a thread: 

while (1) {
     Delay();                 // study for a while
     GoToParty(...);          // go to the party
     Delay();                 // well, everyone needs some sleep
}

Your job is to fill all the needed synchronization and other activities into two functions CheckRoom() and GoToParty(). Your implementation must satisfy the stated conditions. Otherwise, your implementation is not a correct one.

Write a C++ program using ThreadMentor to simulate these activities. Note that you can only use mutex locks and semaphores. Your program will not be counted as a correct one if any other synchronization primitives are used.

Input and Output

The input of your program consists of the following:

Submission Guidelines

General Rules

  1. All programs must be written in C++.
  2. Use the submit command to submit your work. You can submit as many times as you want, but only the last on-time one will be graded.
  3. Unix filename is case sensitive, THREAD.cpp, Thread.CPP, thread.CPP, etc are not the same.
  4. We will use the following approach to compile and test your programs: 
    make                <-- make your program
prog4 8 4 20        <-- test your program
    This procedure may be repeated a number of times with different input files to see if your program works correctly.
  5. Your implementation should fulfill the program specification as stated. Any deviation from the specification will cause you to receive zero point.
  6. A README file is always required.
  7. No late submission will be graded.
  8. Programs submitted to wrong class and/or wrong section will not be graded.

Compiling and Running Your Programs

This is about the way of compiling and running your program. If we cannot compile your program due to syntax errors, wrong file names, etc, we cannot test your program, and, as a result, you receive 0 point. If your program compiles successfully but fails to run, we cannot test your program, and, again, you receive 0 point. Therefore, before submitting your work, make sure your program can compile and run properly.
  1. Not-compile programs receive 0 point. By not-compile, I mean any reason that could cause an unsuccessful compilation, including missing files, incorrect filenames, syntax errors in your programs, and so on. Double check your files before you submit, since I will not change your program. Note again: Unix filenames are case sensitive.
  2. Compile-but-not-run programs receive 0 point. Compile-but-not-run usually means you have attempted to solve the problem to some degree but you failed to make it working properly.
  3. A meaningless or vague program receives 0 point even though it compiles successfully. This usually means your program does not solve the problem but serves as a placeholder or template just making it to compile and run.

Program Style and Documentation

This section is about program style and documentation.
  1. For each file, the first piece should be a program header to identify yourself like this: 
    // ----------------------------------------------------------- 
// NAME : John Smith                         User ID: xxxxxxxx 
// DUE DATE : mm/dd/yyyy                                       
// PROGRAM ASSIGNMENT #                                        
// FILE NAME : xxxx.yyyy.zzzz (your unix file name)            
// PROGRAM PURPOSE :                                           
//    A couple of lines describing your program briefly        
// -----------------------------------------------------------

    Here, User ID is the one you use to login. It is not your social security number nor your M number.

    For each function in your program, include a simple description like this: 

    // ----------------------------------------------------------- 
// FUNCTION  xxyyzz : (function name)                          
//     the purpose of this function                            
// PARAMETER USAGE :                                           
//    a list of all parameters and their meaning               
// FUNCTION CALLED :                                           
//    a list of functions that are called by this one          
// -----------------------------------------------------------
  2. Your programs must contain enough concise and to-the-point comments. Do not write a novel!
  3. Your program should have good indentation.
  4. Do not use global variables!

Program Specification

Your program must follow exactly the requirements of this programming assignment. Otherwise, you receive 0 point even though your program runs and produces correct output. The following is a list of potential problems.
  1. Your program does not use the indicated algorithms/methods to solve this problem.
  2. Your program does not follow the structure given in the specification. For example, your program is not divided into functions and files, etc when the specification says you should.
  3. Any other significant violation of the given program specification.
  4. Incorrect output format. This will cost you some points depending on how serious the violations are. The grader will make a decision. Hence, carefully check your program output against the required one.
  5. Your program does not achieve the goal of maximum parallelism.

Program Correctness

If your program compiles and runs, we will check its correctness. We normally run your program with two sets of input data, one posted on this programming assignment page (the public one) and the other prepared by the grader (the private one). You program must deliver correct results for both data sets. Depending on the seriousness of the problem(s), significant deduction may be applied. For example, if your program delivers all wrong results for the public data set, you receive 0 point for that component.

The README File

A file named README is required to answer the following questions:
  1. Question: How did you make sure that no students can enter while the landlord is in the room and checking? Explain your approach in details.
  2. Question: How did you make sure that the landlord will not leave until all students have left the room? Explain your approach in details.
  3. Question: How did you make sure the message "After checking the room XX times, the landlord retires and is on vacation!" is the last message printed by your program?

You should elaborate your answer and provide details. When answering the above questions, make sure each answer starts with a new line and have the question number (e.g., Question X:) clearly shown. Separate two answers with a blank line.

Note that the file name has to be README rather than readme or Readme. Note also that there is no filename extension, which means filename such as README.TXT is NOT acceptable.

README must be a plain text file. We do not accept files produced by any word processor. Moreover, watch for very long lines. More precisely, limit the length of each line to no more than 80 characters with the Return/Enter key for line separation. Missing this file, submitting non-text file, file with long lines, or providing incorrect and/or vague answers will cost you many points. Suggestion: Use a Unix text editor to prepare your README rather than a word processor.

Final Notes

  1. Your submission should include the following files:
    1. File thread.h that contains all class definitions of your threads.
    2. File thread.cpp contains all class implementations of your threads.
    3. File thread-support.cpp contains all supporting functions such as CheckRoom(), GoToParty(), other functions designed and implemented by you as needed.
    4. File thread-main.cpp contains the main program.
    5. File Makefile is a makefile that compiles the above three files to an executable file prog4. Since we may use any lab machine to grade your programs, your makefile should make sure all paths are correct. Note also that without following this file structure your program is likely to fall into the compile-but-not-run category, and, as a result, you may get a low grade. Before submission, check if you have the proper file structure and correct makefile. Note that your Makefile should not activate the visualization system.
    6. The README file.
    Note also that without following this file structure your program is likely to fall into the compile-but-not-run category, and, as a result, you may get low grade. Therefore, before submission, check if you have the proper file structure and a correct makefile.
  2. Always start early, because I will not grant any extension if your home machine, network connection, your phone line or the department machines crash in the last minute.
  3. Since the rules are all clearly stated, no leniency will be given and none of the above conditions is negotiable. So, if you have anything in doubt, please ask for clarification.
  4. Click here to see how your program will be graded.