Star Formation Problem

(Latest revision 2017/03/31)

CS 3750 First C++ Concurrent Programming Assignment (prog #1)

Look over the contents of the directory "ThreadInfo" in our web space. Read the file HiHo.cpp.html in that directory. It illustrates what you need to know about using function calls from the pthreads package on the CS Lab Macs, and about using the queuing semaphores implemented by the sem.cpp and sem.h files. Make copies of sem.cpp and sem.h for your own use. (Ask any questions you have about this in class.)
Starting with the skeleton program called star.cpp, use queuing semaphores to implement a "star formation" program that spawns 8 'particles' (threads), assigns each of them a position in the star, and causes them each to write a message to standard output when they take their position in the star pattern.

The star has to be built up a certain way. The threads of your program are required to 'respect' that order of the star formation. The threads will have serial numbers 00, 01, 02, 03, 04, 05, 06, 07, and 08. The star 'shape' the program is supposed to build is illustrated by the following figure.
```
            5                 

         1     2             
   8        0        6         
         4     3             

            7                 
```
- Thread #08 cannot join the star until threads #01 and #04 are both in position.
- Thread #07 cannot join until threads #03 and #04 are both in position.
- Thread #06 cannot join until threads #02 and #03 are both in position.
- Thread #05 cannot join until threads #01 and #02 are both in position.
- Thread #04 cannot join until thread #00 is in position.
- Thread #03 cannot join until thread #00 is in position.
- Thread #02 cannot join until thread #00 is in position.
- Thread #01 cannot join until thread #00 is in position.
- Thread #00 can join as soon as it wants.
In general if the number of a thread X is greater than 00, X must wait for one or more 'supporting threads' to get into position before X is allowed to get into position.

It will be your job to add code to the program to synchronize the activities of the threads, and to see to it that the messages the threads write come out in an order consistent with the constraints above.

The synchronization that accomplishes the above must be done by employing the semaphore data types implemented by the files sem.cpp and sem.h. You don't get ANY credit unless you achieve the results with semaphores.

In *addition* to the constraints mentioned above, imposed by the shape of the star, there is also a need to enforce mutually exclusive access to standard output. The constraints above are not enough to guarantee that two threads (say threads #03 and #05) will not try to write their messages concurrently. This could cause the messages from the two threads to be written to the screen in a jumbled interleaving.

We want the message of each thread to be written atomically, on its own separate line of the output. This is really a separate problem. I solved that one for you in the skeleton code. We can discuss that further in class.

Solve the problem in a distributed fashion. In other words, if thread X needs to wait until thread Y is in place, then program thread X and Y to communicate with each other. Don't try to program a 'third party' that tells both X and Y what to do and when to do it. Use semaphores. Keep things simple. Any synchronizations you program must guarantee freedom from all forms of indefinite postponement.

You must use only semaphores to make processes wait for events. In particularly, and importantly, you are not allowed to use a while-loop that keeps iterating until some condition becomes true. You are not allowed to use loops like the ones we studied in Peterson's algorithm, for example. You are also not allowed to use similar loops that repeatedly wait on a semaphore. If a thread needs to wait for some event, it should be able to do that by executing a single wait_sem operation on a sim_semaphore variable.

If you feel you have to program a "wait-loop," you are thinking about the program in the wrong way, and you should get some help from me and figure out a different approach.

The program has a "mother" task that creates the 8 child threads, and you must retain that structure. (Only add code in the manner directed in the comments of the skeleton program.) The group of children must somehow notify the mother thread after all the children have finished writing all their messages. The mother has to make sure all the children have finished with their messages before she exits.
Figure out a protocol that allows the mother and threads to cooperate to do the job indicated above. Once you have decided on the protocol, write it down in pseudo-code form and e-mail it to me by the first due date. You should send me a copy of the star.cpp skeleton program with your pseudo code inserted in the appropriate places - where the "real code" will go later.

By the second due date, send a complete, compilable, listing of star.cpp listing with adequate comments (The bottom line on the question of documentation is that I need to be able to read and understand your program!) Also, place copies of test scripts in a separate file, and e-mail that to me too. (Remember: I don't accept attachments. Send a shell archive as inline text - more about how to do that further on.)

(Beware: since some errors in concurrent programs are timing-dependent, you will need to think of some novel ways to test your program. The file HiHo.c illustrates this. Ask for more details in class.) For source code, send me only the main module, star.cpp, and I will compile it on a CS Lab Mac with my own copies of sem.h and sem.cpp. Your program should work for me if it worked for you. For this assignment, you may work in teams of two (2) people, but you don't have to if you don't want to. If you work in a team, make sure that both names are in your comments! If you don't understand something, ask me questions. Don't expect "magic enlightenment."

More Discussion of the Assignment

When you think about doing this assignment, imagine that the mother thread and each child thread can run on a separate CPU of a tightly-coupled multiprocessor. The program may or may not actually use multiple cores or CPUs. The point of this exercise is for you to write a program that will work on *any* computing system on which multiple processes 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 CPUs. It is possible that the different CPUs have radically different effective speeds. Speed can be affected by the inherent power of the CPU, or by the current load on the CPU. Besides that, it is impossible to tell which CPU will be assigned to which thread. And also, each time we run the program, the assignment of threads to CPUs can be different.

In your program, the mother process creates all the children without delay, immediately after the program starts running. (Don't change that!) The mother must do nothing to direct the creation of the star. 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 controlling process, events can only happen as fast as the boss can approve them. This would defeat the purpose of parallel processing.

I gave you a good skeleton program. Just add code in the places indicated, so that the program starts working correctly. Don't rewrite the program in other ways.

The only interactions ANY child is allowed to have with its mother, after its creation, is that a child is allowed to notify the mother after it has positioned itself in the star and written its message to standard output.

The children must cooperate among themselves, using semaphores for synchronization, to create the diamond. As to the decision of when a child X moves into position, only X and the children that will be supporting X are allowed to participate in the making of that decision.

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 get hundreds of e-mail messages at a time and your subject line allows me to sort messages.)
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: CS3750Prog1Pcode
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: CS3750Prog1Final.

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.