That's not how those kernel modifications work. You can't just use them with a mutex. The idea is that a thread will be able to say, I'm yielding the CPU to this other thread. When you unlock a mutex you don't necessarily want to park yourself. These changes require either an app-level scheduler, or the use of synchronization mechanisms that can better specify what you want in terms of scheduling. An example for such a mechanism would be an API that says: I'm sending a message to this other actor, but I'm going to wait for it to reply. In this case, the implementation would tell the OS, switch me out and switch that other guy in instead.

OK, I was being sloppy in my phrasing (and probably thinking also)!

Trying again: Taking your example benchmark, you aren't really calling any special methods that provide any hints for cooperative threading (to my untrained eye). That's great - you've got a great abstraction. But then, what opportunities for optimization does Quasar have, that are not also available to a JVM using the magic syscall?

I'm sure there's something here, but I'd appreciate a hint!

In theory? Absolutely none. But Quasar is here today (and also has an excellent actor system, a nice Clojure API and more).

Well, I appreciate the honesty!

I'm excited by the idea that threads are going to be "the right way", once these improvements make it out of the 'plex.

I also like that I can get a similar API today with Quasar :-)

Just to clarify: it's not that easy. The syscalls are the first step, and then you'll need a scheduler. Once you have those two, you still need new synchronization mechanisms and APIs.

Quasar doesn't just provide lightweight threads. It has rich libraries that help you make the best of them.

Yes, I'm thinking of the big picture. Might be more like Java 12 than Java 9... Or Quasar today!