從一個任務轉變到另一個任務的實際過程叫作設備場景切換。因為設備場景是處理器專用的，實現設備場景切換的實現也是這樣。那意味著它總是要用匯編來寫。與其向你展示我在ADEOS 中使用的80x86 專用的匯編代碼，不如我用一種類C 的偽代碼來展示設備場景切換tb例程。
void
contextSwitch(PContext pOldContext, PContext pNewContext)
{
if(saveContext(pOldContext))
{
//
// Restore new context only on a nonzero exit from saveContext().
//
restoreContext(pNewContext);
// This line is never executed!
}
// Instead, the restored task continues to execute at this point.
}
例程 contextSwitch()實際上是被調度程序凋用，而調度程序又在那此終止中斷的tb系統調用中被調用，因此它不一定在這里終止中斷。此外，由于調用調度程序的操作系統調用是用高級語言寫的，所以大部分運行任務的寄存器已經被保存到它自己當地的棧中了。這減少了例程saveContext()和restoreContext()需要做的工作。它們只需要關心指令指針，棧指針以及標志位的保存。例程 contextSwitch()的實際行為是很難僅僅通過看前面的代碼來理解的。大部分的軟件開發者以連續的方式思考問題，認為每一行代碼會緊接著上一條代碼破執行。然而，這個代碼實際為并行地執行了兩次。當一個任務（新任務）轉變到運行狀態，另一個（舊任務）必須同時返回到就緒狀態。想一下新任務當它在restoreContext()代碼中被恢復的時候就會明白。無論新任務以前做什么，它在saveContext 代碼里總是醒著的——因為這就是它的指令存放的地方。新任務如何知道它是否是第一次（也就是，在準備休眠的過程）或者是第二次（醒來的過程）從saveContext()中出來的呢？它確實需要知道這個差別，因此我不得不用一種有點隱蔽的方法來實現saveContext()。例程saveContext()不是保存了準確的目前的指令指針。實際上是保存了一些指令前面的地址。那樣，當保存的設備場景恢復的時候，程序從saveContext 中另一個下同的點繼續。這也使得saveContext 可能返回不同的值：當任務要休眠的時候為非零，當任務喚起的時候為零。例程contextSwitch()利用這個返回的值來決定是否調用restoreContext()。如果不進行這個檢測，那么與這個新任務相關的代碼永遠不會執行。
我知道這可能是一個復雜的事件序列，因此我在圖8-3 中說明了整個的過程。