> Threads are heavyweight — switching threads is inefficient, they have considerable memory overhead, and the OS will bog down if you make too many of them.
I didn't realize Posix threads were that inefficient?
First, I can't see why the memory overhead would be anything more than having a separate stack and entry in the TCB?
Second, can you not just save the stack pointer, program counter and registers into the TCB, then do the reverse when restoring a thread?
Finally, I wouldn't have thought you'd have too many TLB misses either, thus leaving the only expense being trapping to the kernel to switch between threads?
Relatively speaking, I don't think context switching is _that_ expensive compared to other areas you can focus on like doing smarter memory management.
I don't know exactly what they mean by threads having heavy memory overhead, but possibly they mean cache interference mentioned in that link? I'd be curious if there is an actual large memory chunk other than stack/scheduling details in play here too.
On modern cores too, there are a decent chunk of registers, including floating point registers. I've looked into timings before for embedded applications and the performance hit here isn't trivial when looking at interrupts and the like; but I'd be surprised if it was that overwhelming on servers.
I didn't realize Posix threads were that inefficient?
First, I can't see why the memory overhead would be anything more than having a separate stack and entry in the TCB?
Second, can you not just save the stack pointer, program counter and registers into the TCB, then do the reverse when restoring a thread?
Finally, I wouldn't have thought you'd have too many TLB misses either, thus leaving the only expense being trapping to the kernel to switch between threads?
Can anyone explain?