(Latest Revision: 11/11/2015)

Parallel Bubble Sort


  1. Read all these directions before starting to work on the assignment.

  2. As needed, re-read the file HiHo.cpp (actually HiHo.cpp.html) in the ThreadInfo directory. It illustrates everything you need to know about using function calls from the pthreads facility on the CS Lab Mac's, and about using the queuing semaphores implemented by the sem.cpp and sem.h files. You may make copies of ThreadInfo/sem.cpp and ThreadInfo/sem.h for your own use, or the identical copies of sem.h and sem.cpp available in the set of resources accompanying this assignment.

  3. Working in a team consisting of just yourself, or of you and one partner of your choosing, use queuing semaphores (as provided by sem.h and sem.cpp) to implement a "parallel bubble sort" program that reads a list of 32 integers from standard input, puts them into an array, sorts them, and writes the sorted array to standard output. If you have difficulty, ask me for help in office hours. Don't look at other team's solutions to this problem.

    You must use this program skeleton as a starter, and solve the problem by adding semaphore variables and semaphore function calls to the skeleton.

    You should make a separate directory on a CS Department Lab Macintosh computer running OS X, place copies of Makefile, bubble.cpp, sem.h, and sem.cpp in the directory, and use the single command make to compile the program.

    Don't make any changes at all to the Makefile, to sem.h, or to sem.cpp. Just make changes to bubble.cpp as required. (Read the rest of these directions for more details about what you need to do to the bubble.cpp file.)

    Code in bubble.cpp causes the main thread (the mother) to spawn 31 "child" threads to do interchanges in the data array called cell[].

    The child threads are assigned serial numbers from 1 to 31. These serial numbers are stored in a particular field of a data structure associated with each thread (idPtr->id). Thread #i is in charge of interchanges between cell #i-1 and cell #i in the array.

    Add a declaration of an array of semaphores to bubble.cpp. Make the array the same size as the data array, so that there will be a separate semaphore to protect each item in the data array Add other code that satisfies these two goals:

    1. enforce mutually exclusive access to each cell (individually) in the data array, and
    2. promote as much parallel processing as possible of the cells in the data array

    The second condition above means that you make it possible for as many pairs of cells as possible to be swapped at the same time. I want you to learn what you can about how to make threads work productively in parallel. Your program may designate one thread (it can be the mother) to check to determine when the sorting has been finished, and to print out the sorted list afterwards. The skeleton bubble.cpp program is set up that way. (See the second half of the function called mother()).

    The code for checking to see if the list is sorted is critical section code, because child threads could be attempting to read/write the array cells at the same time that the mother thread is attempting to check to see if they are correctly ordered. Like any other critical section problem, this one requires some sort of synchronization, and you will need to do something with the semaphores. Be sure to read this discussion before you start writing the code to synchronize the mother's checking procedure with the children's activity. There are some important things to keep in mind when solving the problem that may not occur to you right away.

    If you can figure out a way to make the child threads do the checking and/or printing more symmetrically - with less help from the mother thread, you may alter the code so it does that instead.

    All threads must be synchronized appropriately to insure that a parallel sort of the array is correctly performed, and that mutual exclusion is maintained where required, as well as progress and bounded waiting. If the code does things that hamper the degree of parallel processing, there will be signifiant reduction in credit.

    It's very important that you understand the ideas in the requirements just described above. Make sure to ask questions about things you don't understand. I'll try to bring some things up in class and explain them, but it's your responsibility to try to understand and ask questions about whatever does not seem clear.

    In the finished program, the mother task must not exit until after the list has been sorted and printed. (However, you don't have to guarantee that the mother waits for all the child threads to exit first before she exits.)

  4. At the beginning of class on the due date, place in front of me a printout of a complete, compilable, listing of your modified bubble.cpp file, properly commented, formatted, and easy to read. Do not give me copies of the Makefile, sem.h, or sem.cpp. I want only the code you write. Make sure the names of any and all team members are on the printout.

  5. Before midnight on the due date, e-mail me a copy of your bubble.cpp source code. Use this subject line: "CS3750ProgOne" As I explained above, I want just the C++ code you wrote. Please do not e-mail me copies of the Makefile, sem.h, or sem.cpp. Also don't send me any compiled code - only the source code, bubble.cpp. Don't send me anything as an attachment. I won't accept it. Send the code inline with your e-mail message. From one of the CS Lab Macs, you can use a command like this:

    mail -s "CS3750ProgOne" john@ishi.csustan.edu < bubble.cpp

    My e-mail address is: john@ishi.csustan.edu. I will compile the program you send me on one of the CS Lab Macs, with my own copies of sem.h and sem.cpp. Your program is required to work (correctly) under those testing conditions.

  6. 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.cpp illustrates this. I will compile and run your program as a part of my grading procedure. I may vary the timing of the threads by inserting code in your program. The code will delay threads for random or non-random amounts of time. If this "breaks" your code, it means your code is not a correct solution to the problem. You may ask for more details on this subject in class.


DUE DATES:

For the program due date, see the class schedule.