4 ms·

> why doesn’t the do while tight loop result in 100% cpu usage? The main loop tries to read characters using the getchar() function, which in turn pokes them o

> why doesn’t the do while tight loop result in 100% cpu usage? The main loop tries to read characters using the getchar() function, which in turn pokes them out of a buffer inside the "stdin" FILE struct. If the buffer is empty, somewhere inside the libc, it calls the read() system call on the standard input file descriptor to get more. If the kernel doesn't have any more data to return, the system call blocks. I.e. the kernel marks the thread as waiting for I/O and no longer schedules it. Once the kernel has data, the thread is scheduled again and the read() system call returns. And before the obvious follow up question comes: If all programs are blocking on I/O and the kernel doesn't have any threads to schedule, it schedules an "idle thread" that spends its time slice throttling down the CPU. The CPU usage that process monitor programs are displaying is basically the amount of time a CPU core is running something that isn't the idle thread.

lloeki 6y ago
> it schedules an "idle thread" that spends its time slice throttling down the CPU Specifically (AFAIK, at least back then) on x86 the kernel schedules an interrupt and sends a single HLT[0] instruction, and only wakes up when the interrupt triggers. A smartly set up interrupt would have the CPU wake up only as needed for what is required to unblock the pending blocked operations. Smarter schedulers would go as far as coalescing active events together to rush to idle yet wake up less often, and spend as much time down as possible in increasingly deeper C-states[1]. Back in the day some kernels would loop over NOP[1] instructions, so the CPU would effectively never sleep! [0]: https://en.wikipedia.org/wiki/HLT_(x86_instruction) https://en.wikipedia.org/wiki/HLT_(x86_instruction) [1]: https://gist.github.com/wmealing/2dd2b543c4d3cff6cab7 https://gist.github.com/wmealing/2dd2b543c4d3cff6cab7 [2]: https://en.wikipedia.org/wiki/NOP_(code) https://en.wikipedia.org/wiki/NOP_(code)

lloeki 6y ago

> it schedules an "idle thread" that spends its time slice throttling down the CPU Specifically (AFAIK, at least back then) on x86 the kernel schedules an interrupt and sends a single HLT[0] instruction, and only wakes up when the interrupt triggers. A smartly set up interrupt would have the CPU wake up only as needed for what is required to unblock the pending blocked operations. Smarter schedulers would go as far as coalescing active events together to rush to idle yet wake up less often, and spend as much time down as possible in increasingly deeper C-states[1]. Back in the day some kernels would loop over NOP[1] instructions, so the CPU would effectively never sleep! [0]: https://en.wikipedia.org/wiki/HLT_(x86_instruction) https://en.wikipedia.org/wiki/HLT_(x86_instruction) [1]: https://gist.github.com/wmealing/2dd2b543c4d3cff6cab7 https://gist.github.com/wmealing/2dd2b543c4d3cff6cab7 [2]: https://en.wikipedia.org/wiki/NOP_(code) https://en.wikipedia.org/wiki/NOP_(code)