3 ms·
> Creating more threads won't make context switches happen more frequently This is generally wrong in practice, but for a slightly subtle reason. 1. You can f
by wzdd 10y ago
> Creating more threads won't make context switches happen more frequently
This is generally wrong in practice, but for a slightly subtle reason.
1. You can force a context (or thread) switch whenever you like by performing a blocking operation: calling read() for example, or by waiting on a mutex (as this person was doing). There's no more work to be done until the blocking operation completes, so the kernel finds another process (or thread) to run on the now-spare hardware thread.
2. Applications which create a lot of threads or processes tend to use them as IO workers.
3. The IO worker pattern is to block on read(), do some processing, maybe write(), and then go back to blocking. This means that most of the time the worker thread won't be using its complete timeslice.
4. If lots of IO worker threads are continually doing this, you will get a lot of thread switching (or context switching for processes).
5. Thread switching is fast in Linux, but it's slower than a simple syscall, which is what you'd be doing with an async solution.
- otabdeveloper 10y agoRe: your point 1 -- waiting on a mutex happens regardless of whether you're using blocking or non-blocking IO. If your program only ever makes IO system calls and nothing else, then your point might make sense, but this isn't a realistic real-world assumption. Re: your point 3 -- not using the complete timeslice is not a realistic assumption. If you're creating threads then you're presumably doing some little bit of CPU-intensive work and not just copying bytes from one file descriptor to another. You're making terribly silly assumptions about what kind of work servers actually do, and ignoring the real benefit of async solutions. The real benefit is being able to control how threads switch by yourself instead of using the kernel's builtin 'black box' scheduling algorithms. The problem with the 'black box' is that the kernel might decide to penalize your threads for inscrutable reasons of 'fairness' and then you suddenly get inexplicable latency spikes. Of course rolling your own scheduling is an engineering boondoggle and most people just opt for a very primitive round-robin solution. (Which, incidentally, is what you want anyways if you want good latency.) In which case you might as well create a bunch of threads and schedule them as 'real-time' (SCHED_RR in Linux) and get the same result. (Seriously, try it -- benchmark an async server vs a SCHED_RR sync server and see for yourself.)