Programming Project IV
Due Date: Tuesday, April 30, 2002

In the final programming project, you will explore support that can be used by processes to recover the data manipulated by them. The project will focus on the recovery of data contained in a single address space. Thus, you do not need to implement transactional protocols that ensure atomicity across multiple nodes. Your implementation will ensure atomicity for specified data items when they are accessed in a recoverable region. You will be required to show that even if a process fails during its execution in a recovery region (e.g., it is terminated), it will be able to create a consistent state for its data values after it is restarted.

The data for which recovery has to be provided will be read from one or more persistent segments. These named segments will first be mapped by a process into its address space. You can store such segments in files. The process will start a recovery region and will store current values of the mapped segments into an undo log. At the successful end of a recovery region, modified values will be written to a redo log. The redo log must be flushed for a successful completion of a recovery region. If the recovery region is terminated with an abort operation, the state of the data is restored from the undo log. Also, when data is mapped, the redo log must be truncated to ensure that the latest data is made available to the process. Although there is no completely reliable way to ensure that data stored in recently accessed files has been written out to disk on Unix based machines, you can use calls like sync() to increase the likelihood that flushed log records are indeed stored on disk.

The API you should provide for recoverable data manipulation is similar to what is provided by the light-weight recoverable virtual memory or the Rio Vista libraries. In particular, your library should implement the following calls.

1. init_recovery_library: initializes library data structures.
2. map_segment: maps a named segment at a specified address and copies segment data (perhaps after log truncation) into address space.
3. begin_recover: data accessed after this call should be recovered in case of a problem.
4. end_recover_commit: commit changes made since begin_recover.
5. end_recover_abort: discard changes made since begin_recover.
6. flush_log: flush log to disk.
7. truncate_log: Truncate log records.

You can make simplifying assumptions (e.g., recovery regions are not nested) to reduce the programming effort . Also, you can assume that potentially all of the data mapped from segments may be changed in a recovery region.

You should devise a way to demonstrate that a process that makes use of your recoverable memory can recover data that has been successfully committed. You should also demonstrate that function like log truncation also work correctly.