4 ms·
We had a system like this at my workplace, but it is gradually being replaced with cooperative threads. I don't remember what specific issues we were having wit
by obstinate 10y ago
We had a system like this at my workplace, but it is gradually being replaced with cooperative threads. I don't remember what specific issues we were having with it, but I believe slow adaptation to periodic workloads was one issue. Fundamentally, why hill climb when you can know with certainty exactly how many blocked threads there are in your system.
- ablankst 10y agoFrom [1] "in the case of blocking workloads, it’s extremely difficult to determine the number of threads that optimizes overall throughput because it’s hard to determine when a request will be completed." So the argument they make is that responding to the number of blocked threads directly could lead to an over-correction, where you add a lot of threads to the thread pool when threads are about to unblock. This reduces throughput because you now suffer context switches and poor cache locality. [1] https://msdn.microsoft.com/en-us/magazine/ff960958.aspx https://msdn.microsoft.com/en-us/magazine/ff960958.aspx
- obstinate 9y agoThis is only a problem when you're not scheduling cooperatively. If you are scheduling cooperatively, then you don't ever have to experience unnecessary context switches.