前面我們提到：OS希望在保持控制權的同時，為使用者提供高效能的併發。
那麼OS究竟是如何保持對計算機的控制權呢？這似乎是一個令人迷惑（但很重要！）的問題：OS也是程序，自然也需要計算資源。那既然我們希望一直保持OS的控制權，難道OS需要一直佔用計算資源麼？當然不是這樣。
在微核心OS中，一般有兩種模式 —— 核心模式（Kernel Mode）和 使用者模式（User Mode），普通使用者程序基本都執行在使用者模式中，只能執行一些一般的、基本的操作。那不一般的操作（我們稱之為“特權操作”）有哪些呢？比如I/O操作、中斷處理、時鐘管理、還有相當重要的程序排程操作等，這些“特權操作”只能在核心模式中由作業系統進行，而使用者模式下則不能執行任何特權操作。
上述核心模式與使用者模式的關係類似於什麼呢？其實有點像父母給小孩子的安全屋：所有比較危險的東西（比如帶電的插座、窗戶等）都被保護起來了，小孩子可以在裡邊安全的活動。但是一旦他想做任何“危險行為”，就應該找他的父母來完成那些“危險行為”。
類似的，一旦某個程式希望執行某個特權操作，它就會呼叫OS核心（syscall）來執行，這樣CPU的控制權就被原先的程式移交給了OS。
好，看起來我們已經保證了OS的控制權：透過使用者程序主動syscall移交控制權。但是這個方式沒有解決另外一個問題：如果一個程序一直不願意交出CPU控制權怎麼辦？這樣的程序很容易實現：一個while(true);無限迴圈就行。對於這些不友好的程序，我們該如何處理才能保證OS的控制權？
（想一想，你可以想到的！）
沒錯，我們可以定時將控制權移交給OS，這可以利用時鐘（如石英振盪器）來實現，每隔一段時間定時syscall，強制將計算機控制權移交給OS就行，當然這需要硬體中斷的支援。
綜上，現在我們有兩種方式來保證OS對計算機的控制權：1 友好的程序會主動syscall來移交控制權；2 對於不友好的程序，我們使用定時中斷的方式獲得控制權。
當然，上述兩種方式還帶來了2個新問題：
1. 所有使用者模式的程序在將控制權移交給OS後（或主動或被動），它都相當於從原本的執行狀態被硬生生地打斷了。那麼它下一次執行的時候，我們是不是需要將計算機恢復到它被打斷之前的狀態，從而接著執行呢？沒錯，當然是需要的，我們可以用Process Control Block來實現，這個過程就叫Context Switch —— 上下文切換。
2. OS或主動或被動地獲得控制權後，都必須要決定接下來要執行哪個使用者程序，那麼OS是如何來決定接下來執行什麼程序的呢？這就要透過排程演算法 —— Scheduler來實現。