(Latest Revision: 10/18/2000)
Concurrent Bubble Sort
- Read the file HiHo.cpp in the ThreadInfo
directory. It illustrates everything you need to
know about using function calls from the pthreads
facility on the SUN Ultra's, and about using the
queuing semaphores implemented by the sem.cpp and
sem.h files. Make copies of ThreadInfo/sem.cpp
and ThreadInfo/sem.h for your own use. (We will
go over this in class.)
- Use the queuing semaphores 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. The main thread (the mother)
must spawn 31 "child" threads to do interchanges.
Thread #i will be in charge of interchanges
between cell #i-1 and cell #i in the array. Each
cell must be protected with a semaphore, so that
access to it is mutually exclusive. Your program
may designate one thread (it can be the mother)
that checks to determine when the sorting has been
finished, and prints out the sorted list. If you
can figure out a way to make the threads do the
checking and printing more symmetrically, you may
do that 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.)
- E-mail me a complete, compilable, source listing
with adequate comments. Your program must be very
easy to read. It must be written in a good
programming style. My e-mail address is:
john@ishi.csustan.edu.
Don't send me copies of sem.h or sem.cpp. I will
compile the program you send me with my own copies
of sem.h and sem.cpp. Your program is required to
work under these 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. Ask for more
details on this subject in class.
Problem Scenario:
0 1 2
-------------------
| | | |
| 7 | 6 | 5 |
| | | |
-------------------
P1 P2
- P1 decides to swap slots #0 and #1.
- At about the same time P2 decides to swap slots #1 and #2.
- P1 copies the 6 in slot #1 to a temp variable (temp1).
temp1
-------
| |
| 6 | P1's saved copy of contents of slot #1.
| |
-------
- P2 then swaps slot #1 and slot #2.
The array now looks like this:
0 1 2
-------------------
| | | |
| 7 | 5 | 6 |
| | | |
-------------------
P1 P2
Next P1 finishes it's swap of slot #0 and slot #1:
- P1 copies the 7 in slot #0 to slot #1.
- P1 then copies the 6 in temp1 to slot #0.
Now the array looks like this:
0 1 2
-------------------
| | | |
| 6 | 7 | 6 |
| | | |
-------------------
P1 P2
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.