|
A question that came up from past and present customers considering Linux. I’m not sure that this is the proper forum to post this, although there is a lot of details that will have to be worked out with folks who are focusing on the nptl internals/implementation. Please feel free to direct me to others who are doing work in this area.
Is there a plan to provide hooks to enable user mode lock performance/tracing/debug? This would include: - Lock performance, similar to what the lockmeter project provides but for a user mode threaded application - Lock debugging, for example to extend gdb with the ability to view a lock objects state and manipulate it. Event breakpoint on lock taken, or on lock unavailable. Display the locks that a thread holds. - Tracing tools based on locks.
In general the tools would likely be outside of the charter of this project. But to enable a robust set of tools to do all of these things, make extensions to the libthread_db.so library that lock information could be gotten and set from an attached threaded process, like what is done for thread states and events now in libthread_db.so for gdb. This would involve adding hooks in nptl and libthread_db.so to add interfaces to do this. Gdb and other tools could then use the library to get/set the lock data and generate events for locks.
The APIs to do this in libthread_db.so are not new and are in the public domain already. From a cursory review it looks like /usr/include/libpthread_db.h is already available in RH 9, although it’s not clear that it’s supported as an interface (no man pages). To add in new APIs that follow current practice should not be that difficult. Designing them where there would be minimal/no performance impact on the locking interfaces in nptl as a result of the hooks needed to implement the new libthread_db APIs would be a must.
This should enable what we have with gdb and libthread_db.so, a mostly architecture neutral way to get to the internals of a threaded application. Extending this for lock objects would enable some existing tools for Linux that we are currently lacking.
So, at this point, would there be interest in doing something like this? Actually, are there efforts already underway to do this (likely)? Or, are there reasons that this has not occurred already? It seems that early on getting NPTL solid was key, that is done now and making changes like this can be considered. Are there other tools projects underway already?
Thanks in advance.
Regards, Dave Howell
These are my opinions and not official opinions of Intel Corp.
David Howell Intel Corporation Telco Server Development Server Products Division Voice: (803) 216-2359 Fax: (803) 216-2178
Intel Corporation Columbia Design Center, CBA-1 100 Center Point Circle, Suite 210 Columbia, SC 29210
david p howell intel com
|