Ein Prozeßkontext kann nun freiwillig den Prozessor abgeben, in dem in seinem policy Feld das yield Flag gesetzt und anschließend schedule() aufgerufen wird. Andere Aktivitäten der Prozeßebene können nun die CPU belegen.
Während der Prozeß bei dem beschriebenen Vorgehen bereit bleibt, sein Zustand sich also nicht ändert, kann er aber auch blockieren, in dem vor dem schedule() Aufruf der Prozeßzustand geändert wird. In [BC01] S.75 ist hierzu zu lesen:
Processes in a TASK_INTERRUPTIBLE or TASK_UNINTERRUPTIBLE state are subdivided into many classes, each of which corresponds to a specific event. In this case, the process state does not provide enough information to retrieve the process quickly, so it is neccessary to introduce additional lists of processes. These additional lists are called wait queues.
Ein Prozeßkontext kann also auf ein bestimmtes Ereignis warten, wenn er in die korrespondierende wait queue eingekettet und ein schedule() eingeleitet wird.
Zu diesem Zweck existiert die Funktion sleep_on(), welche den beschriebenen Vorgang transparent macht. D.h. kehrt ein Aufruf dieser Funktion zurück, wurde der gesamte Zyklus bestehend aus Einketten, Blockieren, ,,Aufwachen`` und Ausketten durchlaufen. Der Prozeßkontext befindet sich nun im bereit Zustand. Das Aufwecken übernimmt die wake_up() Funktion.
Es ist hierbei egal, ob ein anderer Prozeßkontext aufweckt oder ein Interruptkontext, beide Szenarien existieren und werden im Kern verwendet. Dabei werden aber nicht in jedem Fall die genannten Funktionen genutzt. Manche Gerätetreiber simulieren den Mechanismus selbständig (siehe Abschnitt 4.3).