System.Threading.Thread.Name is a write-once property. I can assign to it at once, and only then if no other assignment has been made by application or library code. I am writing a multi-threaded event-driven application and would very much like to be able to change the name of the currently executing thread depending on the task its performing at the time.
Does anyone know why this has to be so, or is this a (wrong) presumption on the part of the CLR's designers?
This seems to be by design, my personal guess is that the internal InformThreadNameChangeEx shall be called only once per thread.
You could, however, use a threadstatic field to store the name of the currently running thread and then use this field (for instance for logging).
I found this old blog post saying that it's for consistency.
In my opinion it should be changed back to be settable as much as we like, for the exact scenario you described. When using the thread pool I'll be glad to have a name set for the current task to differentiate easily between those ten paused threads in the debugger.