Proposal: Static call to the OS GetCurrentThreadId

[redknightlois]

I needed the Thread ID to implement some thread aware object pooling mechanism in a very high-traffic and tight hot-spot and was looking to use the Thread ID with a similar implementation to the OS GetCurrentThreadId (and inlined if possible).

mov         rax,qword ptr gs:[30h]  
mov         eax,dword ptr [rax+48h]
ret

However, accessing that would either require me to p/Invoke (I don't have to tell how horrible that code is for a high-traffic tight hot-spot) or use Thread.CurrentThread.GetHashCode or Thread.CurrentThread.ManagedThreadId which need to access the thread object (plus a virtual code in the first case). I can't follow without a checked build for CoreCLR to see how deep the rabbit hole goes, but the Thread.CurrentThread implementation certainly cannot beat a call and 3 instructions (even if not inlined).

The funny thing is that there is a tacit knowledge that getting the ID directly for thread aware code is necessary for high-performance code as showcased by:

        // Helper method to get a logical thread ID for StringBuilder (for
        // correctness) and for FileStream's async code path (for perf, to
        // avoid creating a Thread instance).
        [MethodImplAttribute(MethodImplOptions.InternalCall)]
        internal extern static IntPtr InternalGetCurrentThread();

https://github.com/dotnet/coreclr/blob/master/src/mscorlib/src/System/Threading/Thread.cs#L300

I propose to add:long System.Runtime.InteropServices.Thread.GetCurrentThreadId(); that would inline and call directly to the OS implementation as the internal services are using.

[ayende]

In other places we are caching the thread id in a thread static var, but that has its own issues.

[jkotas]

There is Environment.CurrentManagedThreadId that does almost what you want. It is a bit slower than what it needs to be because of it is coupled with managed thread id, but pretty close.

internal extern static IntPtr InternalGetCurrentThread();

This method is not used anywhere. It would be nice to delete it.

EDIT: It is only used in interop VM code - nothing perf-critical.

[jkotas]

call directly to the OS implementation as the internal services are using

What would you propose the method to return exactly on Windows and Unix? There are multiple different options on each OS... .

[redknightlois]

Unless the id can be bigger I would go with Long as the return type. I don't know if there is any OS out there that uses an ID bigger than 64bits.

[redknightlois]

Linux TID is 32 bits (pid_t) and so is Windows. I would just sign extend it to be on the "safe" side. Given that 64 bits is big enough by current and probably medium term architectures pointers standards... If they are bigger we can just return the pointer to the Thread descriptor (which would work anyways as a UniqueId anyways).

In the worst case, instead of ThreadId we can go for ThreadUniqueHash or something like that, which will map for windows into GetCurrentThreadId and gettid for Unixes. But there are going to be bigger issues of supporting such an architecture than the thread id.

[ayende]

On the mac, that is 64 bits, though. See: http://elliotth.blogspot.co.il/2012/04/gettid-on-mac-os.html

[jkotas]

Linux TID is 32 bits (pid_t)

I do not think there is fast way to get TID on Linux (correct me if I am wrong). gettid is a syscall.

[redknightlois]

Can we get https://github.com/dotnet/coreclr/pull/19002/files#diff-4d40e7e08da7c98543f2bcc0534ad21dR93 to go public somehow?

[jkotas]

https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/api-review-process.md describes how to propose new public APIs.

[jkotas]

https://github.com/dotnet/corefx/issues/18756 looks related.

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.