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 thr

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

Hmmm... In the heavily multi-threaded applications I've written, I've generally had multiple threads executing the same function, so I'm not sure that naming threads is very helpful in that scenario. That said, I did assign each thread an integer ID which was printed in log messages generated by the thread to aid in debugging.

For other applications that had threads with dedicated unique duties, yeah I named them descriptively... but I didn't do this because it was a threaded application, I did it because it is a coding best-practice to do so.

Answer 6

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.