A lightweight thread is a Thread

[Ron Pressler]

On 22 October 2019 at 15:23:09, Mark Raynsford (org.openjdk at io7m.com(mailto:org.openjdk at io7m.com)) wrote:

> On 2019-10-22T14:59:18 +0100  
> Alan Bateman wrote:  
> >  
> > I think we are at the point where we are concluding that a lightweight  
> > thread should be represented by a Thread.  
>  
> Will this not have some nasty consequences when talking to native code?  
>  
> For example, external graphics APIs such as OpenGL and Vulkan have  
> strict restrictions on which threads can make calls into the APIs at  
> any given time. If I'm calling native code, and I specifically create  
> several individual threads for the purposes of doing so... How can I be  
> sure that each thread I've created corresponds to exactly one operating  
> system thread?  

By making it a heavyweight thread. When you create a Thread you choose whether
it is scheduled by the OS (heavyweight) or by the JDK (lightweight).


>  
> I feel like having a distinction at the type level between a Fiber and  
> a Thread makes the difference in cost model explicit, even if there's  
> no other API difference.  
>  
> I'm reminded of FreeBSD, for example, which used to have an m:n model  
> for its own pthreads library, but eventually switched back to a 1:1  
> model for performance reasons. I believe one of the issues was that  
> over a decade of software had grown up around the idea that a thread  
> had a particular cost model (in other words, was a heavyweight  
> scheduling primitive) and that by changing the cost model to an m:n  
> model ended up making most software perform poorly.  


People hardly use the Thread API directly *today*, relying instead on 
j.u.c.Executor and the like. This will likely remain the same with lightweight 
threads: People will use the structured-concurrency constructs to manage them.

Where Thread is used directly is in calls to Thread.currentThread (and, to a
Lesser degree, the interruption mechanism, but that’s a separate discussion).
This use is so pervasive that breaking assumptions about it would mean little
existing code could run in lightweight threads.

Now we get to have our cake and eat it too. Users will mostly interact with
a new API, but those places where Thread is used extensively will continue
working without change.


Ron