These problems should be done on your own. We're not going to be grading them strictly (we'll mainly look at whether you attempted them). But they will be reinforcing knowledge and skills, so you should totally work through them carefully.
Crash recovery
Your friend wants to build a file system that tolerates crashes. Your friend proposes write-behind journaling. In this proposal, there is a journal, but the file system writes to the journal only after checkpointing (“checkpointing”, recall, means applying an operation to the on-disk data structures). Specifically, (1) the file system writes a TxnEnd record for a given transaction only after the TxnBegin record and all journal entries for the given transaction are written, and (2) the file system writes individual journal entries only after checkpointing the operation described by that entry. The recovery protocol looks for incomplete operations (those that are part of a transaction that lacks a TxnEnd record) and undoes those operations, similar to the way that recovery works for undo-only logging.
Assume that a crash can happen at any time. Does your friend’s proposal work? If so, argue that it is correct. If not, explain why not. Use no more than four sentences.
Concurrency Review
Consider the following implementation of a spinlock:
struct Lock {
int locked;
}
int exchange_value(int* ptr, int val) {
int was;
was = *ptr;
*ptr = val;
return was;
}
void acquire(Lock *lock) {
pushcli(); /* disable interrupts */
while (1) {
if (exchange_value(&lock->locked, 1) == 0)
break;
}
}
void release(Lock *lock){
exchange_value(&lock->locked, 0);
popcli(); /* re-enable interrupts */
}Assume that the machine provides sequential consistency. The functions pushcli() and popcli() disable and re-enable interrupts, respectively.
Is the code correct? If the code is correct, explain what invariant is maintained. If the code is not correct, give a problematic interleaving and explain why it is problematic.
Monitors Review
In this problem, you will implement a monitor to help a set of drivers (modeled as threads) synchronize access to a set of five keys and a set of ten cars. Here is the problem setup:
- The relationship between the keys and the cars is that key 0 operates cars 0 and 1, key 1 operates cars 2 and 3, etc. That is, key i works for cars 2i and 2i+1.
- If a key is being used to operate one car, it cannot be used to operate the other.
- A driver requests a particular car (which implies that the driver needs a particular key). However, there may be many more drivers than cars. If a driver wants to go driving but cannot get its desired car or that car's key, it waits until the car and key become available. When a driver finishes driving, it returns its key and notifies any drivers waiting for that key that it is now free.
- You must allow multiple drivers to be out driving at once, and you must not have busy waiting or spin loops.
- We repeat: there could be many, many instances of
driver()running, each of which you can assume is in its own thread, and all of which use the same monitor,mon.
Below, fill in the monitor's remaining variable(s) and implement the monitor's take_key() and return_key() methods. Follow the coding standards given in class.
typedef enum {FREE, IN_USE} key_status;
class Monitor {
public:
Monitor() { memset(&keys, FREE, sizeof(key_status)*5); }
~Monitor() {}
void take_key(int desired_car);
void return_key(int desired_car);
private:
Mutex mutex;
key_status keys[5];
/* ADD MATERIAL BELOW THIS LINE */
};
void driver(thread_id tid, Monitor* mon, int desired_car) {
/* you should not modify this function */
mon->take_key(desired_car);
drive();
mon->return_key(desired_car);
}
void Monitor::take_key(int desired_car) {
/* FILL IN THIS FUNCTION. Note that the argument refers
to the desired car. */
}
void Monitor::return_key(int desired_car) {
/* FILL IN THIS FUNCTION. Note that the argument refers
to the desired car. */
}Handing in the homework
Use Gradescope.