A: It cannot. If the reason you need numeric IDs is to build and operate on the matrices of the banker's algorithm, then the simulator IDs would not be useful anyway: if a process dies, its ID is never reused, so you'd have missing rows in your matrices; similarly for deleted resources and missing matrix columns. Moreover, using the IDs of the simulator would break the separation between the two classes.
Instead, use your own internal maps between allocator objects and integers. You might find some of the provided classes very helpful to maintain these maps efficiently.
A: The simulator is not robust indeed. Some
command-lines (but only invalid ones) will cause a
NullPointerException. But think of the simulator as a
user program. How well it handles its inputs and whether it crashes is
irrelevant to how the OS should behave. Your allocator is conceptually
part of the OS and hence it must abide by a much more stringent
robustness standard.
A: Yes, you may. Here is an example of a fairness policy that requires changing the deadlock detector.
For example, consider a system with 2 resources (R1, R2) and 3 processes (P1, P2, P3). Assume the following sequence of operations:
| Allocation | Request | Available | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
But a fairness policy may interfere with that assumption. For example, it might require that the queue of pending requests is processed in strict FIFO order. In this case, P3 has to be unblocked before P2. If you combine this requirement with the above resource allocation state, the system is already deadlocked! Hence a modified deadlock detector is necessary, specifically one that takes into account the constraints which the fairness policy imposes on request granting.
A: Stub classes are provided java source files in
which you find lines reading ADD CODE HERE IF
APPROPRIATE. In other words, the provided class implementation
is not fully functional. Complete classes are those without such
comments; those are fully functional and you shouldn't need to change
them to complete the programming task (and you are not allowed to do
so).
A: Just use type-casting. For example, suppose you
add the method hello() to BankersProcess,
and you need to call it from a BankersAllocator method
which receives a Process argument p. After
making sure that p was indeed created by
BankersAllocator (mandated by the robustness
requirement), just declare
BankersProcess bp=(BankersProcess)p;and call your new method via
bp.hello().
ProcessTable? Aren't they supposed to simulate part of
useful OS functionality?
A: No, you do not have to use any provided class in this assignment. If you have no use for them, just pretend they were never given to you. In some assignments, you must use certain classes that represent simulated entities (e.g. RAM, hard disks, processes); there are no such classes in this assignment.
Specifically, ProcessTable and ResourceTable
are mere helpers. MainSimulator uses them, and you can
create and use your own instances of those classes within
BankersAllocator. Both classes maintain tables that
assign sequential integers IDs to Process and
Resource instances respectively. These IDs can be helpful
as row/column indices into the martices and vectors of the banker's
algorithm.
A: It is OK. As stated in the requirements, high performance is not a requirement for this assignment. You need not worry about creating dynamically resizable matrices and vectors. Feel free to create a brand new instance of each matrix and vector from your other record-keeping data structures every single time you run the banker's algorithm.