How does the scheduler know that a thread is blocked waiting for input?

Question

When a thread executing user code is waiting for input, how does the scheduler know to interrupt it or how does the thread know to call the scheduler, seeing as the average programmer of a simple single threaded application is unlikely to insert sched_yield() everywhere. Does the compiler insert sched_yield() on optimisation or does the thread just spin lock until the general timer interrupt set by the scheduler fires, or does the user have to explicitly state wait(), sleep() functions in order for the context to switch?

This question is especially relevant if the scheduler is not preemptive because then it has to call the scheduler when it is waiting for input for throughput to be effective, but I'm not sure how it does this.

Collocation

do you have a preemptive kernel? (do you use an os that has a kernel...?) – Contrabassoon

Yes. If it is preemptive then a timer interrupt will exist I believe. – Collocation

When a program waits for input it calls an operating system function to wait for the input. In that case the operating system (and thus the scheduler) knows that your thread is now in status waiting for input. – Macaluso

This was a nooby question because I didnt know much about OSs a few months ago – Collocation

Answer 1

Be careful not to confuse preemption with the ability of a process to sleep. Processes can sleep even with a non-preempting scheduler. This is what happens when a process is waiting for I/O. The process makes a system call such as read() and the device determines no data is available. It then internally puts the process to sleep by updating a data structure used by the scheduler. The scheduler then executes other processes until an interrupt or some other event occurs that wakes the original process. The awoken process then becomes eligible again for scheduling.

On the other hand preemption is the ability of an architecture's scheduler to stop execution of a process without its cooperation. The interruption can occur anywhere in the program's instruction stream. Control returns to the scheduler which can then execute other processes and return to the interrupted (preempted) process later. Most schedulers allocate time slices where a process is allowed to run for up to a predetermined amount of time, after which it is preempted if higher-priority processes need time slices.

Unless you're writing drivers or kernel code, you don't need to worry about the underlying mechanisms too much. When writing user-space applications the key concepts are (1) that some system calls may block which means your process is put to sleep until an event occurs, and (2) on preemptible systems (all mainstream modern operating systems) your program may be preempted at any time so that other processes can run.

^{* Note that in some platforms, such as Linux, a thread is really just another process which shares its virtual address space with another process. Processes and threads are therefore treated exactly the same by the scheduler.}

Mattingly

So since I/O access involves a system call, the kernel function implementation will likely contain functionality to put the thread to sleep until a certain interrupt occurs from the I/O device.. – Collocation

@Lewis Kelsey Yes, exactly right. In most device drivers in Linux, this is accomplished using a wait queue which is a mechanism provided by the kernel for exactly this purpose. – Mattingly

Answer 2

It is not clear to me whether your question is about theory or practice. In practice in every modern operating system, i/o operations are privileged. Meaning that in order for a user process or thread to access files, devices and so on it must issue a system call. Then the kernel has the opportunity to do whatever it considers appropriate. For example it can check whether the I/o operation will block and, therefore switch the running (i.e. “call” the scheduler) process after issuing the operation. Note that this mechanism can work even when there is no timer interruption handled by the kernel. Anyway in general it will depend upon your system. For example in an embedded system where no OS exits (or a minimal one) it could be the entire responsibility of the user’s code to invoke the scheduler before issueing a blocking operation.

Highspeed

Answer 3

Kernel can be preemptive, not scheduler.

First sched_yield() and wait() are types of voluntary preemption, when process itself gives out CPU even if kernel is non-preemptive.

If kernel has ability to switch to another process when time quantum has expired or higher priority process become runnable then we are talking about involuntary preemption, i.e preemptive kernel, and it can happen on different places explained below.

Difference is that insched_yield() process stays in runnable TASK_RUNNING state but just goes to the end of the run queue for it's static priority. Process must wait to get the CPU again.

On the other hand, wait() puts process to a sleep TASK_(UN)INTERRUPTABLE state, on a wait queue, calls schedule() and waits for an event to occur. When event occur, process are moved to run queue again. But that doesn't mean that they will get CPU immediately.

Here is explained when schedule() can be called after process is woken up:

Wakeups don't really cause entry into schedule(). They add a task to the run-queue and that's it. If the new task added to the run-queue preempts the current task, then the wakeup sets TIF_NEED_RESCHED and schedule() gets called on the nearest possible occasion:

• If the kernel is preemptible (CONFIG_PREEMPT=y):

  • in syscall or exception context, at the next outmost preempt_enable(). (this might be as soon as the wake_up()'s spin_unlock()!)
  • in IRQ context, return from interrupt-handler to preemptible context

• If the kernel is not preemptible (CONFIG_PREEMPT is not set) then at the next:

  • cond_resched() call
  • explicit schedule() call
  • return from syscall or exception to user-space
  • return from interrupt-handler to user-space

Legislative