CS 3733 Operating Systems, Fall 2003 Recitation Session 7

Week of October 20.
In this session you will use a producer-consumer, bounded buffer simulator.

1. Log on to your account in the Linux Lab.
2. Create a rec07 directory somewhere under your cs3733 directory.
3. Download this tar file and untar it into your rec07 directory.
4. In that directory, execute runpc. If all goes well you will have started the producer-consumer bounded buffer simulator.
5. Exit the simulator with the Quit button in the upper right corner.
6. Edit the file pcconfig and change the username to your name.
7. Start the simulator again.
8. This is simulating a single producer and a single consumer. Become familiar with the code used by the producer and consumer as displayed in the simulator window. It should seem familiar. The only critical sections are the incrementing and decrementing of the counter.
   In this simulation the critical sections are not protected and so the program can fail.
   • When the producer finds that it cannot insert another item into the buffer because the buffer is full (counter = n) it executes a yield which removes the process from the CPU allowing the consumer to execute. In a similar way, the consumer calls yield when the buffer is empty.
   • The incrementing and decrementing of the counter has been written out as if it were 3 assembly language instructions. This allows the producer or consumer to lose the CPU during its critical section.
   • The number of cycles needed to execute each instruction is shown in the cycles column. For the produce and consume steps it is given as a range [50,100] indicating that the actual number of cycles is chosen randomly between 50 and 100. The actual number of cycles for the current execution is also shown.
   • Scheduling is done round robin with a quantum of 50.
   • The first column of the producer code indicates the number of times the process lost the CPU while (or before) executing the instruction.
   • The second column gives the number of times the instruction was executed. If it says 12+13/50 it means that it was completed 12 times and has done 13 of the 50 cycles needed to execute the instruction.
   • Try out the program using the green One Cycle and 10 Cycles buttons. It will execute using a quantum of 100 and the Quantum Remaining will be shown on the next to last line of the display. You can force a quantum expiration at any time by using the Switch Processes button.
   • At the top of the screen the values of the shared buffer variables are shown along with the contents of the buffer which has size 10.
9. Push the Reset button to reinitialize the simulator.
10. Use the One Cycle and 10 Cycles buttons to run the producer almost two times through its loop.
    • When the producer loses the CPU after about one time through the loop, push the switch button to give it back the CPU.
    • When the producer is about to execute R1 = R1 + 1 for the second time, switch to the consumer. The producer has now lost the CPU during its critical section. Let the consumer run at least until it decrements the counter. Eventually it will switch back to the producer.
    • Run the producer for a few more cycles and look at the values of the shared variables. The producer produced 2 items and the consumer consumed one of them. However, the counter value is 2 instead of 1.
    • This has produced an internal inconsistency with the program. The program thinks that there are 2 values in the buffer, but one of these has already been used by the consumer.
11. The above example shows an internal inconsistency in the program. The program has not yet incorrectly produced or consumed anything, but if the program is run long enough, there is the possibility that the consumer will consume an item it has already consumed. The rest of the experiments you will will examine how long it may take for this to happen.
12. Read the discussion of internal and external inconsistencies in the bounded buffer problem here.
13. Reset the simulator using the Reset button and look at the second column of buttons under the producer window.
    • The last of the buttons there is labeled Failure Type: Internal Inconsistency.
    • Push the green One Run button and the simulator will run until an internal inconsistency occurs.
    • This will occur after a few thousand cycles.
    • Look at the number of times each critical section is interrupted.
    • The critical section is interrupted if the process loses the CPU before the second or third assembly language instruction of the three instructions needed to increment or decrement the counter.
    • An internal inconsistency occurs in the producer if it loses the CPU while incrementing the counter and the consumer gets in and decrements the counter before the producer can finish incrementing the counter.
    • Since in this example the quantum is 100 and the consumer loop takes about 100 cycles to complete, it is very likely that if the producer loses the CPU in its critical section an internal inconsistency will occur.
14. Find the button labeled Failure Type: Internal Inconsistency again and push this button once. It should change to Failure Type: External Inconsistency.
15. Push the Reset button again and open the log file.
16. Push the 10 Runs and the simulator will perform 10 runs, each time running until an external inconsistency occurs.
17. Close the log file and bring up the log file in a browser window. The name of the log file is logfile.html. Look at the two tables at the bottom of the page.
18. The last table categorizes the types of failures. The simulator keeps track of the first internal failure that occurred and shows the number that occurred in the producer and the number that occurred in the consumer. It also lists the two types of external failures that occurred.
19. The interesting table is the one above the last one. It gives the number of cycles before a particular type of event occurred. 10 runs were performed. Look at the column of numbers labeled Average.
    • The first number if the average number of cycles until an external failure occurred.
    • The next two numbers give the average number of cycles executed by the consumer and producer. These should each be about half of the first number.
    • The next number if the average number of cycles before the first internal inconsistency occurred in a given run.
    • The following two numbers break this down into failures that occurred when the producer and consumer were interrupted.
20. Compare the average number of cycles needed to produce an external inconsistency to the average number of cycles before the first internal inconsistency. Recall that the program does not produce incorrect output until an external inconsistency has occurred.
21. Write a short paragraph about what these results tell you about how long it takes an internal inconsistency to manifest itself in the output of a program. Put this at the end of your log file.
22. Put a copy of the log file in your web directory an put a link to it on your CS 3733 web page.
23. Show the TA that you have done this.