Due Date: Friday of week 13]
The following guidelines are expected for all homework submissions:
- All homework must be typed. Homework which is not typed will be returned ungraded and will be
subject to the late homework guidelines as set out on the syllabus page. PLEASE DO NOT scribble
something on lined paper and rip it out of your spiral notebook — hanging chads went out
with the presidential election in 2000.
- I don't care too much about what font you use or how large your margins are; however, you might
want to check out a monospaced font for typing code, as it will be easy to see the indentations.
- Speaking of indenting, PLEASE DON'T USE TABS TO INDENT YOUR CODE. Tabs can often get interpreted
differently by different computers and applications, and could make code that is nicely formatted
on your computer look
all over the map on my computer or printer. USE SPACES INSTEAD.
You can set up almost every modern text editor to insert spaces whenever you press the TAB key, or
you can simply pound the spacebar.
- Work with a partner. I can't stress this enough; part of this policy is don't
split up the work – WORK TOGETHER on the assignment. This activity mimics
an industry code development model called
pair programming which is part of the Extreme
Programming software development method. Feel free to collaborate in your pairs as much as you
want, doing the entire assignment together.
- DO NOT share your work between groups. Doing so will count as plagiarism. If you wish to discuss
solutions with another group over coffee in the Lair, that's fine as long as it is kept at the
conceptual and you don't share your code between groups. Each group needs to turn in its
own version of the solutions.
- You only need to turn in one copy per group.
- Submit your homework through GitHub, in your repository, and be sure to make
me a contributor so I have been allowed access. I cannot evaluate what I
cannot see! If I cannot upload to your repo, you will not get a grade for the assignment.
Problems for Assignment #3
- Write an implementation of the Dining Philosophers program, demonstrating deadlock avoidance.
- Write a short paragraph explaining why your program is immune to deadlock?
- Modify the
file-processes.cpp program from Figure 8.2 on page 338 to simulate this
Write the code in
tr a-z A-Z < /etc/passwd
C, not in C++.
- Write a program that opens a file in read-only mode and maps the entire file into the virtual-memory
address space using
mmap. The program should search through the bytes in the mapped
region, testing whether any of them is equal to the character
X. As soon as an
X is found, the program should print a success message and exit. If the entire file
is searched without finding an
X, the program should report failure. Time your program
on files of varying size, some of which have an
X at the beginning, while others have
X only at the end or not at all.
- Read enough of Chapter 10 to understand the following description: In the
TopicServer implementation shown in Figures 10.9 and 10.10 on pages 456 and 457, the receive method
invokes each subscriber's receive method. This means the TopicServer's receive method will not
return to its caller until after all of the subscribers have received the message. Consider an
alternative version of the TopicServer, in which the receive method simply places the message into
a temporary holding area and hence can quickly return to its caller. Meanwhile, a separate thread
running in the TopicServer repeatedly loops, retrieving messages from the holding area and sending
each in turn to the subscribers. What Java class from Chapter 4 would be appropriate to use for
the holding area? Describe the pattern of synchronization provided by that class in terms that
are specific to this particular application.