property - microsoft constant naming convention c#

Naming conventions for threads? (6)

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?

If you are using a library like ACE the Thread has a way to specify the thread name when creating a new thread.

BSD Unix has also a pthread_set_name_np call.

Otherwise you can use prctl as mentioned by Fusspawn.

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.

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

This question is currently tagged with 'linux' for no apparent reason... anyway, if you're using Visual Studio, the thread name appears in the threads window in the debugger, so if you're debugging an app with tons of threads, the name makes it super-easy to find 'the thread you care about' in this window in the debugger.

In short, I just use it because it interacts nicely with the debugger tooling.

How to name a thread in Linux?

Posix Threads?

This evidently won't compile, but it will give you an idea of where to go hunting. I'm not even sure its the right PR_ command, but i think it is. It's been a while...

  #include <sys/prctl.h>
  prctl(PR_SET_NAME,"<null> terminated string",0,0,0)

Thread names--when do you need to know them?

When looking for connection leaks in java, it is sometimes useful to trace an object back to see which thread it was created by. In our case, it was the Finalizer thread. This led us to the conclusion that things were getting garbage collected, but not being Finalized fast enough. i.e. a bunch of stuff was waiting to be finalized, which was all done in one thread.

As a result, we learnt a lesson about not relying on Finalize.