Userland Lock Profiling and Verification
Project description
The goal of this project is to provide userland versions of the LOCK_PROFILING and WITNESS kernel options. This will require the addition of new, instrumented libraries to the base system build. Modifications to pthread.h will be needed in order to collect file and line information for lock acquisition and release.
One problematic area is the lack of lock names for the pthread locks. Default names will be automatically generated, and additional functions pthread_{mutex,rwlock,etc}attr_setname_np() and pthread_{mutex,rwlock,etc}attr_setname_np() will be added to allow for more user-friendly names to be selected.
Profiling statistics will be available via an external XML file and a pair of new functions, pthread_getprofiledata_np() and pthread_resetprofiledata_np(). Lock order reversals will be logged to an external XML file as well.
Approach to solving the problem
The profiling and lock order verification will be implemented separately.
Profiling will be done via an instrumented version of the pthread library (libthr_profile), while lock order verification will be done with a wrapper library (libwitness). The use of a wrapper library should make the witness library more portable and easier to maintain, while the use of an instrumented library allows the lock profiling code to collect statistics that can only be obtained in an intrusive fashion.
Deliverables
The project will provide:
- Lock profiling data recording and access via library API
- Lock order reversal recording and access via library API
- Logging of statistics to a file
- Data viewer
Milestones
- May 21: Start of coding
- June 1: Lock profiling integrated into build system (stub functions only)
- June 15: Lock profiling code feature complete
- July 9-13: Mid-term Evaluations
- July 6: Data logging feature complete
- July 10: Witness library integrated into build system
- July 27: Witness library feature complete
- August 10: Data viewer
- August 13: End of coding (soft)
- August 20: End of coding (hard)
Test Plan
A test suite will be provided with a number of small cases designed to trigger the monitored scenarios and verify that the values returned by the library API functions are correct. These will be developed concurrently with the data recording functionality.
The data logging will be tested by reading back the statistics file can comparing the results to those returned by the debugging APIs.
The data viewer will probably be tested manually, as automation of the testing process would likely prove to be difficult to do properly.
The Code
The code will be available in the Subversion repository at https://socsvn.freebsd.org/socsvn/soc2012/gmiller/.
Useful links
(Links to any external resources, work, research etc which may be useful to you or to anybody wanting to understand your work)