back

by hackandthink·3y ago·view on hn ↗
Maybe 20 years ago Sun changed the Java threading model from m:n to 1:1. Because of problems.

Loom seems to be a new implementation of m:n Threading for Java. How does your implementation compare?

---

Could not find references from 20 years ago, but this paper from 2014 is nice:

"Earlier M: N was considered best among all because of its performance benchmarks. Currently the Linux and Solaris have shifted from M: N to 1:1 thread model despite of the advantages of M:N. Our emphasis will be on 1:1 Model semantics for shifting. This paper gives a thorough review of operating system thread models. We have researched factors which compelled different OS platforms to shift to 1: 1 Model."

https://www.researchgate.net/publication/270217184_Thread_mo...

4 comments
My understanding is that Java didn't have an M:N thread scheduler before, it had an N:1 scheduler (I believe that all virtual threads were multiplexed onto a single shared operating system thread).

I believe that Loom is the first official M:N thread scheduling implementation for the JVM.

Thank you for this!

I am wondering whether to include S for socket in the syntax for scheduling.

So if you have M:N:S multiplexing you can share a socket over multiple lightweight threads which are themselves assigned to one kernel thread at a time.

My implementation is a toy compared to Loom. Loom is a serious API adaptation which causes the Thread API to work as lightweight threads, I am not sure if it handles process starvation as my M:N scheduler does.

if you put while (true) {} in a lightweight thread, I think that thread shall either be preempted by Loom if Loom implements that or it shall keep the lightweight thread assigned to that kernel thread, causing starvation of other lightweight threads.

So you might have

thread1:light1:socket1recv thread2:light2:socket1send thread1:light1:socket2recv thread1:light2:socket2send

Maybe Sun was simply wrong. Many other languages/runtimes have had great success with M:N threads, including the Erlang runtime.
In Linuxland 20 years ago "Native POSIX Thread Library" an 1:1 implementation won as well (1).

Go's M:N Threading is a great success. I guess M:N threading is harder to implement at the OS Level.

(1) https://en.wikipedia.org/wiki/Native_POSIX_Thread_Library

> Loom seems to be a new implementation of m:n Threading for Java.

Kotlin successfully introduced green threads (viz. coroutines) to the JVM world way back when. Kotlin constructs for structured concurrency are especially super nice.

Scala has had coroutines (async+await) before Kotlin existed, so not sure if "introduced to JVM" is the right word here. But anyway, I agree they are nice in Kotlin.