[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Extending nptl's libthread_db.so interfaces for locking

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.



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]