Some guidelines for this week's studio:
You should see race conditions similar to what you saw in Studio 3. We will fix those, but using a different concurrency control mechanism.
Your implementation should allow only one of the following statements to be true at any given point in a program.
- There are currently no readers or writers.
- There is currently a positive number of readers but no writer.
- There is currently exactly one writer but no readers.
Things to think about:
- Your implementation must keep track, reliably, of the number of readers and writers that have a given RWLock on an object. What does your implementation need to do this and how do you avoid race conditions?
- Stick to the pattern taught in class about how processes threads should use notifyAll and wait.
- Remember that you should only hold any lock for as long as you really need it. Extending that principle to readers/writer, you should only obtain writer lock when you really need it. Use readers locks whenever possible.
- Pay attention to the comments in the Account class about what you should and should not modify.
- Once it is working, show your RWLock implementation and demo it to a TA.
- Complete the questions posed in feedback.txt for this part.
Mazes are supposed to have the following properties:
- All rooms are connected with each other by a unique path.
- There is no cycle among rooms.
For example, the path between rooms 24 and 47 goes: 24, 30, 36, 42, 43, 44, 45 46, 47, and that is the only path between those rooms.
Pick any pair of rooms and convince yourselves there is exactly one path between them.
For example, rooms 7, 8, 13, and 14 are involved in a cycle.
Find more cycles and convince yourselves of the abhorrence of this maze.
To get an idea of the methods you can call on various objects for this lab, consult the JavaDoc for the lab.Bounce your ideas around, and off of other groups, and talk with the TAs and professor about this.
Complete the questions in feedback.txt for this part.