4 ms·
The switch overhead need not be the same. When the OS wakes up a thread and schedules a processor to run it, it has to make sure that said processor has whatev
by anamax 5y ago
The switch overhead need not be the same. When the OS wakes up a thread and schedules a processor to run it, it has to make sure that said processor has whatever state it needs. If said processor was previously doing something else, the OS has to save the relevant state. Note that the OS doesn't know what's important, so both save and restore are conservative.
Yes, switching from one activity to another also has costs, but you only pay what you need to pay and much of the overhead is handled automatically.
That said, blocking-for-IO threads do have one huge advantage - the OS knows when to wake them up. With async, something has to look for changes in IO state. Check too often, and you're wasting time. Don't check often enough and you're wasting bandwidth.
- convolvatron 5y agointerrupts?
- duped 5y agoPolling driven async is faster than callback based async up and down the stack almost without exception, including interrupts. Interrupts are incredibly slow on modern hardware.
- anamax 5y agoInterrupts vs polling hardware is in the OS. Regardless of how the OS handles IO, user code can either poll the OS or have the OS wakeup a thread when there's a change, such as data for a blocking call.
- egberts1 5y agoAs a long-time embedded engineer, I violently recoiled at the over-generalization: “in the OS”. Perhaps “user-land” is that missing aspect. Think how zero-buf embedded network software architect deal with no interrupt and no context switching.
- anamax 5y agoEven in embedded land, there is code that manages IO devices. And, in much/most embedded systems, there is some separation of concerns, if only because such systems do multiple things. Data comes in. Via some combination of device configuration and device handling code, it gets put somewhere. Meanwhile, there's some other code that will process said data, but the system is doing lots of other things. There are two ways to know when to run said "other code". The code that handled the hardware can start said other code or something else in the system can ask "is there new data" periodically. One implementation of "can start" is waking up a thread. Note that the "interrupt vs polling" decision for the "handle hardware" code does not dictate which way is used to know when to run said other code.
- anamax 5y agoInterrupts vs hardware polling is in the OS. I'm writing about how user code gets "data ready" from the OS, which is independent of how the OS handles hardware.
- egberts1 5y agoYour last sentence makes more sense. But it is in no way related to your first.