Re: #79519

While implementing thin locks for NativeAOT I noticed that making calls to runtime to figure location of ManagedThreadId is a considerable expense (relatively, as all other parts of the lock implementation are fairly cheap).

Note that in NateviAOT the managed thread ID is dispensed and managed on the managed side. That is because native thread and managed thread object may outlive each other and we need to keep the ID unique as long as either is alive.

The part that the ID is dispensed and set from managed code should not prevent the optimizations. We basically need to somehow intrincify/inline the computation of the managed thread ID location, then the regular implementation that initializes the ID on demand should work just fine.

In fact only reading path is perf critical. We will write to the location not more than once per life time of the thread.

Similar optimization may be applicable to CoreClr as well. CoreClr also makes a method call when accessing managed thread ID.