Hacker News Reader

I didn't watch the preso (TL;DW) but isn't this just a case of good old fashioned Priority Inversion? https://en.wikipedia.org/wiki/Priority_inversion

If so, it's pretty much an intractable problem, and is the reason (for example) why Solaris abandoned the two-level thread model and went back to a single level one? https://flylib.com/books/en/2.830.1.14/1/

But then again, as I said, TL;DW ;-)

View on HN

I think this is a bit more subtle and nasty than bog standard priority inversion. Specifically, in present virtual threads, if you take out a lock with synchronized, if you then do a normally-non-blocking asynchronous API call while you have the lock, you block one of your very few OS threads because the virtual thread can't now be migrated off the OS thread.

IMO the compound thing is what makes it be nasty. E.g. you have a function `doSomething` which does some RPC, and that's all nicely non-blocking. But someone called map.computeIfAbsent(x, k -> doSomething(k)), and that uses synchronized on the inside so now your non-blocking API calls all magically became blocking, no further action required.

Thanks for the explanation and - Ugh :-(

Reply on news.ycombinator.com