71 lines
2.3 KiB
HTML
71 lines
2.3 KiB
HTML
|
<HTML>
|
||
|
|
<HEAD>
|
||
|
|
|
||
|
|
<BR>
|
||
|
|
|
||
|
|
Neil Bergmann at Queensland University of Technology, Australia
|
||
|
|
created this project. Thanks Neil!
|
||
|
|
|
||
|
|
<BR>
|
||
|
|
<BR>
|
||
|
|
<BR>
|
||
|
|
|
||
|
|
<B>The Dining Philosophers </B>
|
||
|
|
<p>
|
||
|
|
This assignment deals with one of the famous problems in
|
||
|
|
resource allocation, deadlock and synchronization.
|
||
|
|
Copy a proposed solution to the Dining Philosopher's
|
||
|
|
problem, <tt>dine.cm</tt> (BACI C-- syntax)
|
||
|
|
from the common directory of larkspur.
|
||
|
|
Execute the program 50 times and record how often the
|
||
|
|
philosophers eat and how often they deadlock.
|
||
|
|
(BACI prints out system diagnostics when it detects deadlock,
|
||
|
|
i.e. when all threads in the system are blocked.)
|
||
|
|
Identify the problem that exists in this solution to the
|
||
|
|
Dining Philosophers, and fix the problem such
|
||
|
|
that your solution is independent
|
||
|
|
of the number of philosophers. Execute the program at least
|
||
|
|
50 times and confirm that deadlock doesn't occur in
|
||
|
|
your solution.
|
||
|
|
<p>
|
||
|
|
Written deliverables:
|
||
|
|
<OL>
|
||
|
|
<LI> A listing of your revised code; highlight the parts of
|
||
|
|
your revised code that are different from the original.
|
||
|
|
<LI> A brief explanation of why the original program deadlocks, and also an
|
||
|
|
explanation of how the diners sometime do manage to
|
||
|
|
eat in this program.
|
||
|
|
|
||
|
|
<LI> A brief explanation of how your solution corrects the
|
||
|
|
problem discussed in 2., emphasizing why
|
||
|
|
your solution <i>never</i> deadlocks.
|
||
|
|
|
||
|
|
<LI> An illustration of the results from 50 executions (in a compact
|
||
|
|
format!),
|
||
|
|
which shows that your solution never deadlocks. (You can add a
|
||
|
|
for-loop to the main program outside the cobegin to help make this data
|
||
|
|
collection easier.)
|
||
|
|
|
||
|
|
<LI> Show the results from your compact 50-executions
|
||
|
|
when you change your program to four
|
||
|
|
dining philosophers and then to three dining philosophers.
|
||
|
|
The only parts of the code that should change for these different
|
||
|
|
executions is the number of calls to <tt>dine()</tt> in the cobegin/coend
|
||
|
|
block.
|
||
|
|
|
||
|
|
<LI> A brief explanation to the following three questions:
|
||
|
|
<OL type=a>
|
||
|
|
<LI> Is your algorithm robust against deadlock when the number of diners
|
||
|
|
change? Explain.
|
||
|
|
<LI> Is your algorithm fair in the sense that every diner has a chance
|
||
|
|
to be the first to eat? Explain.
|
||
|
|
<LI> If diners took an hour to eat their spaghetti, what is
|
||
|
|
the longest and shortest time that five diners would take to
|
||
|
|
eat using your algorithm? Explain.
|
||
|
|
</OL>
|
||
|
|
</OL>
|
||
|
|
|
||
|
|
</BODY>
|
||
|
|
</HTML>
|
||
|
|
|