Thread.GetHashCode uniqueness

[user2150]

"In managed threading, Thread.GetHashCode is the stable managed thread identification. For the lifetime of your thread, it will not collide with the value from any other thread, regardless of the application domain from which you obtain this value."

But from here (Thread.GetHashCode Method): https://docs.microsoft.com/en-us/dotnet/api/system.threading.thread.gethashcode?view=netframework-4.8

"The hash code is not guaranteed to be unique. Use the ManagedThreadId property if you need a unique identifier for a managed thread."

Apparently, the latter statement is incorrect as GetHashCode and ManagedThreadId both return the same value and seem to be the same because GetHashCode actually returns m_ManagedThreadId (although it's unclear how it is initialized).

Since there's no feedback capability in the GetHashCode article, I post here.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 2e267fd4-6615-49ca-c77f-c97ecdbacb9b
• Version Independent ID: 95febe7e-6407-4be4-484d-1621db41c5e7
• Content: Managed and Unmanaged Threading in Windows
• Content Source: docs/standard/threading/managed-and-unmanaged-threading-in-windows.md
• Product: dotnet
• Technology: dotnet-standard
• GitHub Login: @rpetrusha
• Microsoft Alias: ronpet

[mairaw]

Thanks for your feedback @user2150. @kouvel can you comment on this issue about Thread.GetHashCode? By looking at the code, it seems that both return the same value. Potentially, we should also review https://docs.microsoft.com/en-us/dotnet/api/system.threading.thread?view=netframework-4.8#getting-information-about-and-controlling-threads.

[kouvel]

Yes it looks like they currently return the same value. GetHashCode() doesn't have to return the managed thread ID though, for instance it could just return what object.GetHashCode() would return in the future. So in that sense I don't think the statement above is necessarily incorrect, and for people looking for a unique identifier it's not a bad thing to redirect them to the ManagedThreadId property, which would be preferable for that purpose. I don't feel too strongly about it though, it's unlikely that the implementation would change.