SerialSebThread ids and Hashcodes
dasBlonde is blogging about the GetHashCode vs GetCurrentThreadId way of getting a thread id. Without knowing what exactly she is trying to accomplish, it seems to me that GetHashCode shouldn’t be used in the same way as the GetCurrentThreadId.
Did I mention how much I love her blog? A very technical and very classy woman, and a must read for anyone!
If you’re trying to get the logical thread id, GetCurrentThreadId gives you that, and you can rely on it to be stable for the lifetime of your process. Very useful for tracking code execution path for example.
GetHashCode on the other hand gives you something else (from the MSDN documentation):
Serves as a hash function for a particular type, suitable for use in hashing algorithms and data structures like a hash table.
Thanks to my huge pst file, newsgator, my memory still working well and my paranoid archiving of everything, notice this post. What does it tells us? That the contract on the GetHashCode method is to provide a reasonably random value, but that could be negative or duplicated for multiple values. The guarantee is even getting weaker (or the lack of getting stronger) in v2.
What else can we know about the GetHashCode functionality defined on the Object class? I had a nice email chat with Brian Grunkemeyer back in October, and I actually learnt something that I didn’t foresee: A hashcode can be duplicated (it is non unique) AND it may change during the lifetime of an object, no guarantee is made. I quote him here (hope he doesn’t mind):
String has always used a hash function that could generate repeatable values – Object's implement of GetHashCode was the one that didn't generate repeatable values (for the lifetime of a given object). Now this repeatability isn't a problem – any well written hash table expects collisions in a bucket and has to do an equality check on the two objects first, using Object::Equals(Object) or an equality method provided by another comparison interface, like IComparer. So normal hashing shouldn't be affected by this.
There you go. GetHashCode has a pretty weak contract that suits mostly the developers of the Hashtable, full stop. Thread Id on the other hand gives you the guarantee that your thread id is going to be unique to this thread. Just imagine if two threads were sharing the same Id? Thread Id collision would be a real disaster!
And finally, to complete this post with yet another API (what wouldn’t anyone do to take over the first google return from .net247!), the Process.Threads return ProcessThread objects which do have ThreadId. As this post from Chris Brumme explains, u shouldn’t ever rely on that at all, as the CLR is actually “virtualizing” the OS threads, and you may also encounter the garbage collection thread, and additional internal CLR threads…