Add direct access to the thread id

[jsimmons]

Proposal

Add direct access to the thread id.

Problem statement

Accessing the thread id requires first accessing the thread context, which is not free. The thread context itself is an Arc, and so grabbing the current thread context requires at least an atomic fetch-add, atomic fetch-sub and injection of the drop handler in the caller.

The assembly works out something like this:

        push rbx
        sub rsp, 16
        call qword ptr [rip + std::thread::current::current]
        mov qword ptr [rsp + 8], rax
        mov rbx, qword ptr [rax + 16]
        lock dec qword ptr [rax]
        jne .DONE
        lea rdi, [rsp + 8]
        call qword ptr [rip + alloc::sync::Arc<T,A>::drop_slow]
.DONE:
        mov     rax, rbx
        add     rsp, 16
        pop     rbx
        ret

Where std::thread::current looks up the Thread in TLS, and then Thread::id looks up the id field.

However if we access directly, it's a singular TLS load in the good case, and the same lookup via the Thread in the worst case - but without the Arc maintenance.

Something like...

    push rbx
    mov  rbx,0xffffffffffffffe0
    mov  rax,QWORD PTR fs:[rbx]
    test rax,rax
    je .SLOW
    pop  rbx
    ret
.SLOW:
    call QWORD PTR [rip+std::thread::ThreadId::new]
    mov  QWORD PTR fs:[rbx],rax
    pop  rbx
    ret

Furthermore, the existing current_id implementation (internally) promises to not invoke the global allocator, which is helpful in embedded / realtime contexts especially.

Motivating examples or use cases

On a work-queue push:
https://github.com/tikv/grpc-rs/blob/edb4d961cd71a3758f015577c577f6e3f735b6f4/src/cq.rs#L165-L172

Wrapping non-send types in a sendable wrapper:
https://github.com/mitsuhiko/fragile/blob/7631a72b0a4a47fb8251cc2ad641f3db8fd1b565/src/fragile.rs#L41-L46

Manually caching the thread id in TLS for performance:
https://github.com/SAP/transactional-storage-framework/blob/e84d92edf5999660fb8448831a610840def50e66/src/utils.rs#L25-L41

Non-allocating access to the thread id to the thread id:
https://github.com/robbert-vdh/nih-plug/blob/ecfd6322c776d9f0373d31758976c2353c162737/src/event_loop/linux.rs#L61-L65

Solution sketch

rust-lang/rust#143069

Alternatives

Leave it as-is.

Links and related work

The C++ std exposes a free function for accessing the thread id. https://en.cppreference.com/w/cpp/thread/get_id.html

[edwloef]

I'd love to see this happen as well, in order to be able to identify threads in a realtime-safe(r) manner. See e.g. https://github.com/robbert-vdh/nih-plug/blob/ecfd6322c776d9f0373d31758976c2353c162737/src/event_loop/linux.rs#L61-L65

[the8472]

Do you need ThreadId's no-reuse guarantee or would the operating system's tid be sufficient?

[jsimmons]

Do you need ThreadId's no-reuse guarantee or would the operating system's tid be sufficient?

Not sure if this was in relation to above, or a general question. But the ThreadId invariant on reuse is very valuable for most of these cases, as it allows you to use the thread-id as a gate for upholding safety invariants.

[joboet]

Great idea!

Furthermore, the existing current_id implementation (internally) promises to not invoke the global allocator, which is helpful in embedded / realtime contexts especially.

Note that realtime usage still isn't a good idea since current_id might need to allocate a TLS key, which could lead to locking or allocation inside libc.

[joshtriplett]

👍 for adding this. This seems completely reasonable, and the patch is quite small (mostly documentation).

[the8472]

We discussed this during today's libs-api meeting. Adding a Thread::with_current(closure) or Thread::ref_current() -> ThreadRef where impl !Send for ThreadRef where brought up as more general alternatives to get access to the current thread object without incrementing the ref count.

Would those work for you?

[jsimmons]

Personally, I think that might be a bit excessive since there's only three methods on Thread, and only one of them is really relevant in a performance sensitive context. But I don't have any strong objection to something like ref_current() (even though that's still not as efficient as just exposing the singular tls lookup required for thread id, it'd be fine)

[kennytm]

What functions and traits exists for ThreadRef? I suppose it should not be Copy? And Sync may be troublesome

[the8472]

ThreadRef.as_ref(&'a self) -> &'a Thread, so unpark, id, name.
The lifetime guarantees that ThreadRef is alive, ThreadRef: !Send means it must live on originating thread, which means the reference can't outlive the thread. We're not relying on destructors here so afaict the leakpocalypse doesn't apply.

[FeldrinH]

ThreadRef.as_ref(&'a self) -> &'a Thread

If you can directly convert ThreadRef to &Thread and there is no relying on destructors then why not just do Thread::ref_current() -> &Thread?

[jsimmons]

ThreadRef.as_ref(&'a self) -> &'a Thread

If you can directly convert ThreadRef to &Thread and there is no relying on destructors then why not just do Thread::ref_current() -> &Thread?

Just returning &Thread would be returning a value which is Send, and you don't have any lifetime other than 'static to bind it to. In contrast the ref you'd get from ThreadRef is bound to the lifetime of the ThreadRef (and thus, since it's !Send, the thread itself) so it cannot escape.

[programmerjake]

just returning ThreadRef is unsound:

fn get_static_thread() -> &'static Thread {
    let thread_ref: &'static mut ThreadRef = Box::leak(Box::new(Thread::ref_current()));
    thread_ref.as_ref()
}

fn cause_ub() {
    let reference_to_dead_thread = spawn(get_static_thread).join().unwrap();
}