A lightweight thread is a Thread

[David Lloyd]

On Wed, Oct 23, 2019 at 12:38 PM Andrew Haley <aph at redhat.com> wrote:
> On 10/23/19 1:49 PM, David Lloyd wrote:
> > On Wed, Oct 23, 2019 at 3:59 AM Andrew Haley <aph at redhat.com> wrote:
> >>
> >> On 10/22/19 5:27 PM, David Lloyd wrote:
> >>> One would still have to allow subclassing of threads though IMO, even
> >>> in the lightweight case.  This is enormously useful
> >>
> >> What is it about subclassing Thread that is enormously useful? I can't
> >> immediately think of any case where a scoped local couldn't achieve the
> >> same thing. Instead of
> >>
> >>    (MyFoo)Thread.current();
> >>
> >> you'd have
> >>
> >>    CurrentFoo.get();
> >>
> >> ... which would work in lightweight and heavyweight Threads. Is there
> >> something that definitely wouldn't work with this mechanism?
> >
> > Apart from being the fastest possible way to have thread local values
> > in Java,
>
> I don't think you'd notice any difference:
> [...]
> That's 6 clock cycles (@ 3.5GHz) for the scoped value, 5 for the field
> in Thread. Darn! :-)

Nice!  That's very cool.

> > Vert.x/Netty uses a custom thread subclass to support "faster"
> > thread locals (though looking at the code I suspect these "faster"
> > thread locals might be heavier than the JDK's thread local support).
>
>     @Benchmark
>     public void getFieldFromFastThreadLocal(MyState state) {
>         Sink.getSink().drain(BenchmarkState.f1.get());
>     }
>
> Benchmark                                   Mode Cnt  Score   Error  Units
> ThreadLocalTest.getFieldFromFastThreadLocal avgt   3  2.287 ± 0.063  ns/op
>
> [8] clocks. That's actually pretty damned good considering they
> didn't touch the JVM. There is the trade-off, though, that every
> thread that uses this has a fixed-size array of thread locals at least
> as large as the highest-numbered FastThreadLocal it uses.
>
> It's a really sweet idea, but I'm not sure I could get away with it
> in a general-purpose facility because of scaling issues. Food for
> thought...

Nice, that's better than I expected given my initial impression of the
complexity of the classes involved.

> > Sometimes you want to be able to do `ThreadSubclass foo =
> > notCurrentThread(); foo.something();`.  From what I understand, one
> > can't easily get a scoped local for some other thread.
>
> True. Apart from any other issues I don't do anything thread-safe. TBH
> I'm not sure if this is safe for ThreadLocal either, unless they are
> very careful about concurrent access to the pool of ThreadLocals.

Right of course much (perhaps most) of the time that thread local
values are used, the values are explicitly and deliberately not thread
safe.  So you wouldn't normally use that facility for this kind of
thread attachment.  But maybe a generalized thread attachment
mechanism is called for.  OTOH perhaps allowing access to the Runnable
via a simple getter on Thread would accomplish the exact same thing in
a very similar way to what subclassing Thread would do?

-- 
- DML