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?

Solution 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() )

Solution 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.

Solution 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.

Solution 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.

View more solutions