Comments on: Managed Thread Ids – Unique Id’s that aren’t Unique

By: Gibraltar 2.1.1 Released :: Rock Solid

Gibraltar 2.1.1 Released :: Rock Solid — Fri, 19 Feb 2010 05:14:28 +0000

[...] users to restart Analyst. Ouch. Fortunately we were able to figure it out and fix it. We addressed Thread Ids [...]

By: Kendall

Kendall — Tue, 16 Feb 2010 21:59:31 +0000

I might have been more clear – I’m honestly not sure if they’re resetting the name but I presume they are. We were showing the name as duplicate because we captured the thread name the first time and assumed if we keep seeing the same thread Id then the additional metadata (like name) goes along with it.

What is really interesting is the speed that we’re seeing it happen which makes me suspect they actually are recycling the thread under the covers: We find that this reproduces pretty quickly where if you create a thread, use it for a short time and release it then cause activity on the thread pool the ID shows up there even if there are other Ids that it could use (for example gaps in the numbers). It could be that threads are so expensive that it’s “sanitizing” the thread and keeping it around to optimize the case where people are creating & destroying threads a lot instead of using thread pools.

By: Jason Short

Jason Short — Tue, 16 Feb 2010 21:54:36 +0000

Sounds to me like they are recycling it, but not resetting the name. So if another thread is spun up, and doesn’t explicitly set the name, it can be reused. That is bad behavior to me.

All objects being initialized should have all their member variables reset to known states, not just left to the previous value.

It is ok to hold and recycle objects, but they should never have left over state or information from the previous run. Imagine if you got a new string back from the system and it already had a string present in it… Not expect (and no, it doesn’t happen). So I wonder why it happens for Threads.

By: Kendall

Kendall — Tue, 16 Feb 2010 16:43:15 +0000

The point is that the documentation doesn’t specify that the uniqueness is bounded in time. It says this is the unique identifier for the managed thread. Without any other decoration it’s completely ambiguous whether that’s bound or not. It’s the ambiguity that’s a problem – particularly since this appears to be bounded by a very short period of time (we’ve seen duplication in a matter of a few seconds). Contrast this with Process Id – it’s exactly and clearly documented how unique this is. There’s no need to play detective and infer what’s going on. Likewise the documentation on unmanaged Thread Id’s is very clear.

We’re not bothered that they are recycled – far from it – it’s more the challenge of writing good documentation and how ambiguity in documentation can get your customers in trouble.