(1 item) |
|
(1 item) |
|
(5 items) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(6 items) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(4 items) |
|
(2 items) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(2 items) |
|
(5 items) |
|
(3 items) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(3 items) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(8 items) |
|
(2 items) |
|
(7 items) |
|
(2 items) |
|
(2 items) |
|
(1 item) |
|
(2 items) |
|
(1 item) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(5 items) |
|
(1 item) |
|
(3 items) |
|
(2 items) |
|
(2 items) |
|
(8 items) |
|
(7 items) |
|
(3 items) |
|
(7 items) |
|
(6 items) |
|
(1 item) |
|
(2 items) |
|
(5 items) |
|
(5 items) |
|
(7 items) |
|
(3 items) |
|
(7 items) |
|
(16 items) |
|
(10 items) |
|
(27 items) |
|
(15 items) |
|
(15 items) |
|
(13 items) |
|
(16 items) |
|
(15 items) |
A few days ago, dasBlonde blogged about the use of thread IDs and
Thread.GetHashCode. The Technologist replied
here,
and then dasBlonde posted a follow-up. I thought I'd join in.
I was about to write about how I don't really understand why dasBlonde says you can't just use GetHashCode in
VB.NET, but I realise Michele is ahead
of me on that one...
Meanwhile, The Technologist suggested that GetHashCode was the wrong approach. He said:
"If you're trying to get the logical thread id, GetCurrentThreadId gives you that"
No it doesn't. Or at least not in general. It gives you the physical thread ID (i.e. the underlying Win32 thread ID), which is not necessarily the same thing.
It's true that in V1.0 and V1.1 of the CLR (i.e. the versions shipping today), in any given AppDomain there is a one to one mapping between logical CLR threads and physical Win32 threads. However, this has never been guaranteed - it's just an implementation detail of these versions. In fact people from Microsoft have been suggesting that this is likely not to be the case in future versions right from the start. This quote from Brad Abrams dates back to July 2000:
"we didn't make it very easy to obtain the threadid from a managed thread... that is because in general, we don't want to encourage people to obtain the ThreadId of a thread because it limits our ability in the future to break the 1:1 correspondence between managed threads and OS threads (e.g. implementing fibers in the runtime)."
This is not just a hypothetical problem - in V2.0 of .NET, this one to one mapping will indeed cease to exist in certain scenarios. Chris Brumme talks about this in his extensive item on hosting - search for "M:N" in that, and you'll see a discussion of two issues, both of which break anything that assumes the physical thread ID tells you anything about the logical thread ID: (1) a given physical thread may carry multiple logical threads, and (2) a given logical thread may migrate from one physical thread to another over time.
So if you're looking for a dependable logical thread identifier, the Win32 thread ID is The Wrong Thing.
The thread's hash code is however guaranteed to provide a unique identifier, as it says here. (Thanks to Mark Allan for pointing this
out to me, and enabling me to remove the horrible code I had in an earlier version of this entry... I'm pretty sure that at one point in
history this was an undocumented feature. I failed to turf this up earlier when
I wrote this blog, because strictly speaking, the Thread.GetHashCode method that this page refers to doesn't
actually exist! Thread just inherits the implementation from Object, and Object.GetHashCode's
documentation makes no such guarantee.)
But then as Michele points out, if all you want is an easy way to work out which thread you're looking at in the debugger,
just setting the thread's Name property is usually a better bet.