| 20.1 | The locking in _db_dodelete is somewhat conservative. For example, we could allow more concurrency by not write-locking the free list until we really need to; that is, the call to writew_lock could be moved between the calls to _db_writedat and _db_readptr. What happens if we do this? |
| 20.2 | If db_nextrec did not read-lock the free list and a record that it was reading was also in the process of being deleted, describe how db_nextrec could return the correct key but an all-blank (hence incorrect) data record. (Hint: look at _db_dodelete.) |
| 20.3 | At the end of Section 20.8, we described the locking performed by _db_writeidx and _db_writedat. We said that this locking didn't interfere with other readers and writers except those making calls to db_store. Is this true if mandatory locking is being used? |
| 20.4 | How would you integrate the fsync function into this database library? |
| 20.5 | In db_store, we write the data record before the index record. What happens if you do it in the opposite order? |
| 20.6 | Create a new database and write some number of records to the database. Write a program that calls db_nextrec to read each record in the database, and call _db_hash to calculate the hash value for each record. Print a histogram of the number of records on each hash chain. Is the hashing function in _db_hash adequate? |
| 20.7 | Modify the database functions so that the number of hash chains in the index file can be specified when the database is created. |
| 20.8 | Compare the performance of the database functions when the database is (a) on the same host as the test program and (b) on a different host accessed via NFS. Does the record locking provided by the database library still work? |
