Thread Native ID Access

[David Holmes]

On 23/02/2018 3:04 PM, John Rose wrote:
> On Feb 22, 2018, at 8:49 PM, David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
>>
>> I don't think this request has any impact on Fibers at all. At any 
>> given time a piece of executing Java code is executing on a current 
>> Thread, and that current Thread must be running on a native thread 
>> (regardless of mapping) and the native thread has an id. The only use 
>> for exposing such an id is to allow you to correlate information 
>> obtained from inside the VM, with information observed outside, 
>> possibly by external tools.
> 
> We may or may not bind fiber identity to the legacy java.lang.Thread type.

I'm not assuming that exposing native thread ids implies anything about 
the binding between those entities and anything higher-level. I have no 
issue with a Fiber/Continuation/Task/whatever running on different 
java.lang.Threads over its lifetime. For that matter I don't think it 
matters if java.lang.Threads could execute on different native threads 
(they don't but they could).

David
-----

> This affects the question of whether the following code can return false:
> 
> boolean testThreadShift(Runnable r) {
>    Thread t0 = Thread.current();
>    r.run();
>    Thread t1 = Thread.current();
>    return t0 == t1;
> }
> 
> This method can return false if (a) Thread.current() reports the identity
> of the OS thread (not the fiber currently running), and (b) the runnable
> includes a blocking operation which causes the current fiber to reschedule
> on a different OS thread before it returns.
> 
> Having this method return false is, perhaps, surprising enough to cause
> us to inject fiber identity into java.lang.Thread, so that a 
> java.lang.Thread
> identity is 1-1 with a fiber, rather than an OS "dinosaur" thread.  (You can
> only pick one!)  The alternative is to keep a 1-1 identity between OS 
> threads
> and java.lang.Thread instances, making a new type which carries fiber
> identity that multiplexes in a scheduler-dependent way over OS threads.
> 
> It's an interesting trade-off, with many compatibility concerns.
> I think we are leaning toward injecting fiber identity into Thread,
> although this makes me shudder to think of the overheads we
> will buy with this one move (ThreadLocal hash tables).
> 
> So, now if you reify the OS thread identity, you could have the same
> issue again.  Can this routine return false?
> 
> boolean testNTIDShift(Runnable r) {
>    long t0 = NativeThreadID.current();
>    r.run();
>    long t1 = NativeThreadID.current();
>    return t0 == t1;
> }
> 
> I think, if you are digging down all the way to the native thread ID,
> this routine *must* be allowed to return false under a Loom JVM.
> There's no credible way to assign unique int64_t IDs to fiber objects
> in the Java heap, as if they were OS objects.
> 
> So my question is, do the proposed use cases for NTID allow
> for testNTIDShift to return false?  If not, then it's pretty easy to say
> that we don't want to supply NativeThreadID.current() for general
> use, just to people implementing schedulers.
> 
> — John