I'm working on an API assembly that will be used by an application or
another API.  I don't have any control over when or how threads are
created.  My API is equipped with tracing for debugging purposes.
Since my assembly can be used in by a multithreaded application, I
want to put some form of thread identifier in the trace log which will
help determine the sequence of events when something goes wrong.

From what I've read in this and related groups on the subject,
AppDomain.GetCurrentThreadId() makes an interop call to get the OS
thread id.  I don't really want this because a) interop calls are
expensive and b) because from what I read elsewhere, it is not safe to
assume a 1-to-1 correspondence between OS thread id and managed
thread.  I need something which uniquely identifies a managed thread;
I don't really care at this point what the CLR does to implement a
managed thread with OS level threads.

I can see that ProcessThread gives you back a thread Id property, but
it looks like this is the OS thread id and if that isn't guaranteed to
be 1-to-1 with the managed thread (particularly at coming releases of
the .Net framework), I'd rather not rely on it.  I haven't been able
to find how to get from a ProcessThread to a Thread as from
Thread.CurrentThread.  Besides, if this is a lower level thread, then
an interop call is probably required.

I've seen where others have used
Thread.GetCurrentThread.GetHashCode(), but I'd rather not use that
since hash codes, by definition, are not guaranteed to be unique.
However, in practice, is the Int32 returned by GetHashCode unigue?
This would imply that there is a theoretical limit of Int32.MaxValue
threads; I guess this should be plenty until some unforeseeable time
in the future.

Any other suggestions?

I'm almost guessing at this point that the designers of the CLR
decided against exposing something call Thread.Id, which would be
managed, because it could so easily be confused with the unmanaged
thread id.