3 ms·
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 https://e
by crustycoder 3y ago
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 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/ https://flylib.com/books/en/2.830.1.14/1/
But then again, as I said, TL;DW ;-)
- CHY872 3y agoI 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.
- crustycoder 3y agoThanks for the explanation and - Ugh :-(