A lightweight thread is a Thread

Mark Raynsford org.openjdk at io7m.com
Tue Oct 22 15:36:10 UTC 2019


On 2019-10-22T16:07:14 +0100
Ron Pressler <ron.pressler at oracle.com> wrote:
>
> On 22 October 2019 at 15:23:09, Mark Raynsford (org.openjdk at io7m.com(mailto:org.openjdk at io7m.com)) wrote:
> > 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).

Ok, good.

> > 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.

Ok, right. I too fall into the camp of pretty much only using the
Executor/ExecutorService constructs - except where native code forces
me to do otherwise. I was concerned when I saw Alan's original email
that the ability to have any say in whether something was a Thread or a
Fiber would be taken away.

-- 
Mark Raynsford | http://www.io7m.com



More information about the loom-dev mailing list