Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

To explain more, suppose we have a dual core CPU without hyper threading, that means it can process 2 threads at once only, well, now suppose we have a network application that is running two background network threads, each one is waiting for incoming connections to handle, so those threads should be running all the time, now, why the the another OS's processes and threads is still working ?! as it appears to me, they cannot be processed because there are two threads fully drain the CPU processing unit because they are waiting for network incoming connections and therefore, they should be ready each nanosecond for connections ... How does that happen and work ? How CPU can handle many and many threads at once without any noticeable freezing ?! (I know, sometimes, windows becomes slow and crazy if there are a lot of heavy programs run at once, but that is not general issue)


share|improve this question
Because the OS handle the scheduling – Ramhound Aug 15 '14 at 23:52

The answer is relatively simple: when a thread is waiting for an I/O event, it yields the rest of its time slice to the OS which can then schedule another thread. When the high latency I/O has completed, the thread is marked as ready for execution.

This is largely possible because most I/O is managed with interrupts rather than repeatedly checking to see if the I/O request has completed (known as polling).

share|improve this answer
A thread can be either waiting or running but not both at the same time. – David Schwartz May 30 at 19:52
@DavidSchwartz With synchronous I/O, rather than writing "is waiting for an I/O event, it yields" I could have more accurately written "requests the next I/O data and allows the OS to deschedule the thread until more data is available". Even with asynchronous I/O the thread would still be waiting for the I/O but would still be running while waiting (like a user waiting for an email while using the computer). (A callback function would allow a thread to process the new data as soon as possible or coarse-grained polling could be used, checking for new data after a work unit is completed.) – Paul A. Clayton May 30 at 23:33
With traditional polling, a thread is both waiting (not necessarily doing any useful work (similar to spin lock) though a polling loop might include useful work (not that a lock-wait loop cold not)). With hardware-managed events (like x86's MONITOR/MWAIT), a thread can be running (OS perspective) and waiting (hardware perspective). With coarse-grained hardware multithreading, an I/O register read (which are traditionally not allowed to be cached) might cause the hardware scheduler to switch threads yet from the OS perspective it is still running. – Paul A. Clayton May 30 at 23:33

If you use cooperative multitasking and have a bad program: then yes, you are right.

However in the real world the following is supposed to happen:

  1. Cooperative multitasking: I tread does not keep using the CPU forever. Instead it will either give another program a chance after some time or when it is blocked.
    Paul's answer describes the latter.

  2. Preemptive multitasking (used just about everywhere): The OS (not the program) will give the CPU for short period of time to a program, and then take it away. This can be as simplistic as running a timer and once that expires stopping the process and giving it to the next tread/program which is waiting.

In your case think of it as an office with two workers and three (or more) tasks. (Lets call them task-A, task-B and task-C).

The first worked checks the supervisors orders which state:

  • Set a timer 10 minutes. When it goes off stop working on your current task, put it at the bottom of the TODO list and continue reading this document.
  • Next remove the first item from the top of the TODO list and start working on it.
  • Repeat.

Worker 1 set the timer and gets the first task of the TODO list (in this case that is task-A).

Worker 2 does the same thing: It sets a timer and gets what is now from the top of the TODO list. Since worker 1 removed task-A from it worker 2 now starts on task-B.

Ten minutes later the timer goes off. Worker 1 stops working on Task-A and gets the supervisors instructions. Those state to put the current task at the bottom of the TODO list. Continuing the supervisor's instructions it now restarts the timer and start to work on what is now at the top of the TODO list (which is task-C).

Worker 2 does the same and stops task-B and starts with the top of the TODO list (which in the example is task-A)

Etc etc..

This is somewhat simplified. But it should give you an idea how two treads (workers) can work 100% of the time on three or more tasks.

In real schedulers there are many more things. E.g. interrupts (compare it to a phone ringing in the middle of a task and how to handle that), smart scheduling (giving the same task to the same worker will likely result in it getting done faster since the worker is already familiar with it), I/O (if a worker needs a book from a library (s)he will not wait until the timer expires, but immediately continues with the next task, etc etc.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.