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?
