38

In the synchronous/blocking model of computation we usually say that a thread of execution will wait (be blocked) while it waits for an IO task to complete.

My question is simply will this usually cause the CPU core executing the thread to be idle, or will a thread waiting on IO usually be context switched out and put into a waiting state until the IO is ready to be processed?

JamieP
  • 1,664
  • 2
  • 13
  • 16

4 Answers4

45

A CPU core is normally not dedicated to one particular thread of execution. The kernel is constantly switching processes being executed in and out of the CPU. The process currently being executed by the CPU is in the "running" state. The list of processes waiting for their turn are in a "ready" state. The kernel switches these in and out very quickly. Modern CPU features (multiple cores, simultaneous multithreading, etc.) try to increase the number of threads of execution that can be physically executed at once.

If a process is I/O blocked, the kernel will just set it aside (put it in the "waiting" state) and not even consider giving it time in the CPU. When the I/O has finished, the kernel moves the blocked process from the "waiting" state to the "ready" state so it can have its turn ("running") in the CPU.

So your blocked thread of execution blocks only that: the thread of execution. The CPU and the CPU cores continue to have other threads of execution switched in and out of them, and are not idle.

e0k
  • 6,961
  • 2
  • 23
  • 30
  • @RyanVincent: A user-space process can use memory directly, without having to make a system call. [A process waiting on cache misses is still tying up a CPU core](http://stackoverflow.com/questions/19980070/which-one-will-workloadusage-of-the-cpu-core-if-there-is-a-persistent-cache-mi). Same goes if using a busy-wait spinlock for thread synchronization. When waiting on anything else, it's the kernel that will receive a notification. It will wake up the thread(s) that were waiting on that disk block or network packet. – Peter Cordes Feb 28 '16 at 23:04
  • Also, low prio tasks on Linux always get some CPU. Minimum prio is not "only if the CPU is otherwise idle", to avoid deadlocks if a low prio process is holding onto a resource or something. Apparently supporting a true idle-priority would make the scheduler more complicated because it would have to check when it was safe to completely starve a process. So this would slightly slow down scheduling even when not using it, thus Linux doesn't include it. So every process that's not waiting on something will receive some timeslices. – Peter Cordes Feb 28 '16 at 23:07
  • @PeterCordes, thanks for the explanation - it helps. – Ryan Vincent Feb 28 '16 at 23:12
  • Thanks, one question though. So If a process makes a network call, it waits for a socket to receive a response, so that a process can read that data from a socket. Until then a kernel puts that process in waiting state. But how does a kernel know that a socket received a response, and a process can be resumed? I guess, a kernel monitors sockets' state? Or sockets just notify a kernel that they are ready to be read? – Vadim Samokhin Nov 03 '22 at 07:47
0

For most programming languages, used in standard ways, then the answer is that it will block your thread, but not your CPU.

You would need to explicitely reserve a CPU for a particular thread (affinity) for 1 thread to block an entire CPU. To be more explicit, see this question:

You could call the SetProcessAffinityMask on every process but yours with a mask that excludes just the core that will "belong" to your process, and use it on your process to set it to run just on this core (or, even better, SetThreadAffinityMask just on the thread that does the time-critical task).

Community
  • 1
  • 1
DevShark
  • 8,558
  • 9
  • 32
  • 56
  • Affinity is the opposite of that: it marks a thread as only being eligible to run on a limited set of CPUs. It *doesn't* stop other tasks from using that CPU. There was a recent question about how to reserve a core for a process recently, but I can't find it. – Peter Cordes Feb 28 '16 at 22:59
  • You can use affinity to exclude other processes from running on the core where the thread is running. – DevShark Feb 29 '16 at 07:14
  • @DevShark You're thinking of using CPU affinitiy + isolcpus (in Linux for example) – GL2014 Nov 13 '20 at 17:59
0

If we assume it's not async, then I would say, in that case, your thread owning the thread would be put to the waiting queue for sure and the state would be "waiting".

Context-switching wise, IMO, it may need a little bit more explanation since the term context-switch can mean/involve many things (swapping in/out, page table updates, register updates, etc). Depending on the current state of execution, potentially, a second thread that belongs to the same process might be scheduled to run whilst the thread that was blocked on the IO operation is still waiting.

For example, then context-switching would most likely be limited to changing register values on the CPU regarding core (but potentially the owning process might even get swapped-out if there's no much memory left).

stdout
  • 2,471
  • 2
  • 31
  • 40
-5

no,in java , block thread did't participate scheduling

吴志新
  • 1
  • 2