Name Your Threads

Tue, July 22, 2008, 02:15 AM under ParallelComputing
One of my pet peeves is ensuring that whenever there is code that explicitly creates a thread, to always have an accompanying statement that names the thread. This is invaluable in debugging. With managed code, it is so simple, just one extra statement to set the thread's Name property (which you can only do once at runtime, of course).

This is such a useful thing to have when debugging, that in VS2008 the ability was added to name threads after execution had started. The idea there is for naming Threads that you don't control but still need to easily identify for debugging purposes. The name does not persist cross debugging sessions and indeed it is not used at runtime by anything other than your... eyes. I describe this feature as part of my video on all the new VS2008 threading enhancements (watch minutes 06:00 through 08:20, although I recommend the full 15 minutes).

At the OS level the ability to have names against threads is not supported (but you can use nice HEX ids to assist with your debugging ;)). Recently I discovered that there is an old trick (or hack IMO) that you can use with certain tools (inc. Visual Studio) to set names on native threads too. To get the details visit this short How To on MSDN. I did a quick search and discovered two more places on the web where this is described. One is on codeproject which is blatantly lifted from MSDN but it adds a couple of screenshots. The other also points to (an obsolete place on) MSDN and adds a bit more detail.

In short, for my managed friends: Search your code base now for the string "= new Thread" and for every match that you find, verify that you are also setting the Name property. You'll thank me later.
Thursday, July 24, 2008 3:34:00 AM (Pacific Daylight Time, UTC-07:00)
I have always looked for custom threads in code that have no name as it is one of my pet peeves too.

It would be handy if static analysis tools picked up on this (I don't believe they do).

It is also a shame that the background worker component doesn't allow the thread to be named (though from the way it works this is understandable).
RichardOD
Sunday, August 17, 2008 3:06:00 AM (Pacific Daylight Time, UTC-07:00)
RichardOD: Yeah, I think the bw component uses the ThradPool so it would not be possible to name the Thread. Still, I would have liked the ThreadPool itself to name its threads something that distinguishes them from user threads...
Tuesday, December 23, 2008 11:29:00 AM (Pacific Standard Time, UTC-08:00)
Is there any way to set a thread name for an application that is not beign debugged (to see that name in a crash dump later) ?
Friday, February 13, 2009 8:34:25 AM (Pacific Standard Time, UTC-08:00)
Alexander, I am afraid I don't have an answer for your question. May I suggest the MSDN forums: http://forums.microsoft.com/msdn/default.aspx?siteid=1
Monday, February 15, 2010 1:35:11 PM (Pacific Standard Time, UTC-08:00)
For thread name identification outside the debugger, I use log4net with %thread in the layout, e.g.:
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%date [%thread] %-5level %logger [%property{NDC}] - %message%newline%exception" />
</layout>
Comments are closed.