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
- 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.
These are my opinions and not official opinions of Intel Corp.
Telco Server Development
Server Products Division
Voice: (803) 216-2359 Fax: (803) 216-2178
Columbia Design Center, CBA-1
100 Center Point Circle, Suite 210
Columbia, SC 29210
david p howell intel com