(Latest Revision: 11/11/2015)
Parallel Bubble Sort
- Read all these directions before starting to work on the assignment.
- 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.
- 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:
- enforce mutually exclusive access to each cell
(individually) in the data array, and
- 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.)
- 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.
- 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.
- 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.