(Version Date: Sun Nov 10 18:56 PST 2013)
Concurrent Bubble Sort Assignment
- For a refresher on using function calls from the Pthreads
facility on the CS Lab Mac computers, and for examples of how to
use the queuing semaphores implemented by the sem.cpp and sem.h
files, read the file HiHo.cpp (actually HiHo.cpp.html) in the
class ThreadInfo directory. If you don't have them yet, make
copies of ThreadInfo/sem.cpp and ThreadInfo/sem.h for use with
the source code you write to solve the problem I am giving you in
this assignment. Do not modify your sem.cpp or sem.h files. I
am going to use my own original copies of sem.h and sem.cpp to
compile your program, and everything is required to work that
way, on one of the CS Lab Mac computers. Let me know if you have
any questions about the basics of Pthreads or my implementation
of counting semaphores.
- Working alone or in a team of two, according to your preference,
use the queuing semaphores to implement a "parallel bubble
sort" program that reads a list of 32 integers from standard
input, puts the integers into an array, sorts them, and writes
the sorted array to standard output.
Your program must provide for as much parallel processing as
possible. In other words, all work that *can* go on in parallel
must be *allowed* to go on in parallel. Your program must not
"force" tasks to proceed serially if they do not need, for
correctness, to proceed serially.
The main thread (the mother) must spawn 31 "child" threads to do
interchanges (swaps). The way you must implement the algorithm,
thread #i must perform the swaps between cell #i-1 and cell #i in
the array. What does that mean? For example, thread #4 is
responsible for doing any needed swaps between cell 3 and cell 4
of the array.
Each cell must be protected with a semaphore, so that access to
each cell is mutually exclusive. You must not allow more than
one thread at a time to access any of the cells of the array.
Under these conditions, if you code correctly, it will be
possible for up to 16 swaps to be happening
simultaneously, if that many processors are
available on the computer running the program.
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. If you can figure out a way to make
the threads do the checking more symmetrically, you may code up
your solution that way instead. All threads must be synchronized
appropriately to insure correct operation, mutual exclusion,
progress, and bounded waiting. 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.)
You must use this program shell as a
starter. Just add some code to it to make it work correctly, and
to conform to the constraints explained above.
- At the beginning of class on the due date, place in front of me a
printout of your completed bubble.cpp file. Together,
bubble.cpp, sem.h, and sem.cpp must comprise a complete,
compilable, source listing of a solution to the problem. The
code you write must be neat, well-formatted, highly readable, and
suitably documented. DO NOT give me copies of sem.h or
sem.cpp, since I have my own copies, and I don't need or want
yours. If you work with a partner, make sure both of your
names are on the printout.
- Before midnight on the due date, e-mail me a
shell archive (shar) file,
containing a copy of your bubble.cpp file, together with one or
more
test scripts
showing that the program worked on one of the CS Lab Mac
computers.
DO NOT send me anything as an attachment. I never accept
attachments from students.
Include only the files I asked for above, nothing else.
DO NOT include sem.h, sem.cpp, or the Makefile. I have my own
copies of those, and I don't need or want your copies. DO NOT
try to include any compiled code in the shar file (for
heaven's sake!).
Use this subject line: "CS3750ProgTwo"
Send the shar file inline with your e-mail message. From one of
the CS Lab Macs, you can use a command like this:
mail -s "CS3750ProgTwo" john@ishi.csustan.edu < myFiles.shar
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.
- Read the Problem Scenario below at the end of this file, to get a
feel for why synchronization is needed when several child threads
share the work of sorting an array.
- Also read the file
Discussion of a Parallel Bubble Sort to get an appreciation
of what can go wrong if a thread checks to see if an
array is sorted at the same time that other threads are
still working on sorting the array.
Problem Scenario:
0 1 2
-------------------
| | | |
| 7 | 6 | 5 |
| | | |
-------------------
C1 C2
- C1 decides to swap slots #0 and #1.
- At about the same time, C2 decides to swap slots #1 and #2.
- Next, C1 copies the 6 in slot #1 to a temp variable (temp1).
temp1
-------
| |
| 6 | C1's saved copy of the contents of slot #1.
| |
-------
- C2 then swaps slot #1 and slot #2.
The array now looks like this:
0 1 2
-------------------
| | | |
| 7 | 5 | 6 |
| | | |
-------------------
C1 C2
Next, C1 finishes its swap of slot #0 and slot #1
by doing the following operations:
- C1 copies the 7 in slot #0 to slot #1.
- C1 then copies the 6 in temp1 to slot #0.
Now the array looks like this:
0 1 2
-------------------
| | | |
| 6 | 7 | 6 |
| | | |
-------------------
C1 C2
We see that two threads each tried to swap a pair of items in
the array. The result was that one of the items in the array
disappeared and one item was duplicated.
This shows that the results of a concurrent bubble sort will
not necessarily be correct unless we synchronize the threads
somehow.
DUE DATES:
For the program due date, see
the class schedule.