Naming conventions for threads?

Question

It's helpful to name threads so one can sort out which threads are doing what for diagnostic and debugging purposes.

Is there a particular naming convention for threads in a heavily multi-threaded application that works better than another? Any guidelines? What kind of information should go into the name for a thread? What have you learned about naming your threads that could be helpful to others?

Apoplectic

Answer 1

There's to my knowledge no standard. Over the time I've found these guidelines to be helpful:

• Use short names because they don't make the lines in a log file too long.

• Create names where the important part is at the beginning. Log viewers in a graphical user interface tend to have tables with columns, and the thread column is usually small or will be made small by you to read everything else.

• Do not use the word "thread" in the thread name because it is obvious.

• make the thread names easily grep-able. Avoid similar sounding thread names

• if you have several threads of the same nature, enumerate them with IDs that are unique to one execution of the application or one log file, whichever fits your logging habits.

• avoid generalizations like "WorkerThread" (how do you name the next 5 worker threads?), "GUIThread" (which GUI? is it for one window? for everything?) or "Calculation" (what does it calculate?).

• if you have a test group that uses thread names to grep your application's log files, do not rename your threads after some time. Your testers will hate you for doing so. Thread names in well-tested applications should be there to stay.

• when you have threads that service a network connection, try to include the target network address in the thread name (e.g. channel_123.212.123.3). Don't forget about enumeration though if there are multiple connections to the same host.

If you have many threads and forgot to name one, your log mechanism should output a unique thread ID instead (API-specific, e.g. by calling pthread_self() )

Doubtless

Answer 2

Naming threads is useful and you should follow a naming convention that would for anything else, be that variables, methods or classes. Name them according to what they do and be succinct. If you ever run into a problem that requires a thread dump it will be nice to look at the name and know where to look in your code for the problem rather than examining stack traces and guessing.

The only different is that if there are multiple threads of the same type you really should add an index of some sort as thread names should be unique to satisfy certain APIs. It can also help with logging if you show the thread name to know how your application behaves with partial execution happening on different threads.

Nix

Answer 3

while Thorsten's answer is the most comprehensive, you might want to look at how Tomcat names its Threads. I've found that useful. We were running multiple threads with a quartz scheduler and many of the naming rules that Thorsten suggests were useful.

Are you going to be using a Thread pool ? If yes, then that will reduce the chances that you can add more useful meta info. If not, the sky is the limit to how much useful info you can have.

Roguish

Answer 4

What about:

[namespace].[Class][.Class...].[Method][current thread]?

So you have the names:

Biz.Caching.ExpireDeadItems1
Biz.Caching.ExpireDeadItems2
Biz.Caching.ExpireDeadItems3

etc., for each thread.

Apoplectic

Answer 5

I've seen several naming conventions for threads in .NET.

Some prefer using 't' in the beginning of the name (ex. tMain Thread) but I don't think it has any real value. Instead why not just use plain descriptive names (line variables) such as HouseKeeping, Scheduler and so on.

Diabolize

Answer 6

I'd like to contribute an pattern that I have begun using to make my thread names meaningful. As I see it, a thread is like a worker who performs a task. As such, I like to look at the task the thread is to perform, and give the thread a name that identifies it as the performer of that task.

For instance, a person whose task is to mop a floor might be called a janitor. In this case Mop(floor) would be my task and janitor would be my thread. In C#, my code might look something like,

Thread janitor = new Thread(() => Mop(floor));
janitor.Start();

Or, if I have a stream that I want to monitor for incoming data, then the task is to monitor a stream. The thread, who's duty is to perform that task would be a stream monitor.

_streamMonitor = new Thread(() => Monitor(stream));
_streamMonitor.Start();

Luthern

Answer 7

I tend to approach naming threads the same as naming methods or variables. Pick something that concisely describes the process that the thread is responsible for. I don't think there's a lot of extra information that you can or should put into a thread-name. Expressive but terse is the primary goal.

The only convention might be to add an incremented suffix to threads that are part of a pool.

Mendacious