Shared Work Piece Problem

(Rev: Sat Nov 26 04:48 PST 2016 )

CS 3750 SECOND C++ Concurrent Programming Assignment (prog #2)

The following diagram represents the assigned problem.

                              Boss
                              buffer

                  Worker #1  Worker #2  Worker #3

                             Finisher

Basically the problem is to synchronize a program in which a boss thread puts a series of work pieces in a buffer and three worker threads process each work piece before passing it along to another thread for finishing.
To learn further details about the nature of the problem, make a copy of the worker.cpp program, and read the program header comments.
You need to add declarations and synchronizing instructions into a copy of the program to make it properly perform as required.

You may use (only) ordinary variables and queuing semaphores as implemented by sem.cpp and sem.h to achieve the synchronization of threads.

Errors in concurrent programs tend to be intermittent. They tend to be manifested only under certain timings of events. The random delays in the program will tend to make the timing of events change each time the program is executed. If you run the program several times and check the output you may be more likely to find out about possible errors than if you just run the program one time and check the output.

For this assignment, you may work in teams of two (2) people. If you work in a team, make sure that both names are in your comments!

Discussion of the Computing Environment to be Assumed

When you think about doing this assignment, assume that the program will execute on a (tightly coupled) multiprocessor. That means all the threads (the boss, finisher, and the workers) could run simultaneously on separate CPU's. While this may or may not actually be true, it will help you write code that will work on *any* computing system on which multiple threads can execute concurrently while sharing variables.

A tightly-coupled multiprocessing system can be diagrammed this way:

  CPU     CPU     CPU      CPU     CPU     CPU   CPU    MEMORY
    |       |       |        |       |       |     |    |
 ------------------------------------------------------------ BUS
       |      |       |     |     |     |     |     |     |
     CPU    CPU     CPU   CPU   CPU   CPU   CPU   CPU   CPU

Here we have a RAM memory being shared over a common bus by several CPU's. It is possible that the different threads could run at radically different effective speeds. Speed can be affected by the inherent power of the CPU, by the current load on the CPU, or the scheduling algorithm used. It is impossible to predict which CPU will be assigned to which thread, and each time we run the program, the assignment can be different.

In your program, the mother process creates child threads to be the workers and the boss. Then the mother thread plays the role of the finisher. The mother does nothing to direct the boss and workers after she creates them.

In general it is a bad idea to create "traffic cop" threads, because the traffic cop too often becomes a bottleneck. When every action has to be approved by a master, events can only happen as fast as the master can approve them. This would defeat the purpose of parallel processing. (Having "traffic cop" threads also goes against the idea of the Progress Condition for critical section problems.)

The general rules for submitting assignments by e-mail are:

Always send me e-mail as plain text in the main message body. Never send me attachments.
When you send a program source file, you also send a script of your tests. Combine the source file and the script into one shell archive (shar) file.
I will tell you what subject line to use with each message, and I need you to use exactly the subject lines I give you. (I sometimes get hundreds of e-mail messages in the span of a few days. I need to search for your subject line to find your message.)
Send each submission before midnight on the due date.

Here is the list of things you have to turn in:

On the first due date e-mail a psuedo-code description of the algorithm for your solution (in-line in a copy of the skeleton program). Use this subject line: CS3750Prog2Pcode
On the second due date e-mail a shar file containing:
- the completed program source code
- one or more script(s) documenting thoughtful, adequate, intelligent testing
Use this subject line: CS3750Prog2Final.

Note that there are no spaces in the subject lines given. It is important that you do not insert any spaces. My e-mail address is: john@ishi.csustan.edu.

DUE DATES:

For due dates, see the class schedule.