應用程式程式碼對事件進行處理。應用程式碼的控制流程起源於一個迴圈，該迴圈對事件佇列進行讀取。對一個佇列來說，多個寫入者是可取的，但是一般來說最好只有一個讀取者。如果你出現了需要多個讀取者得情形，最好問問自己是否你真正需要的是多個佇列。

主迴圈最主要的特色是如何識辨EventQueueEntry並且如何選擇呼叫合適的函式。有時候，我們應該考慮從使用者介面不同部分產生的事件是否可以被不同的任務進行處理，通常這將會使得系統看似更加並行執行以及更好的響應時間。例如，一個單一的任務用來處理按鍵按下，另外一個可以用來處理超時事件，另一個可以處理錄影帶插入和移除事件。為了保護對輸出硬體以及公共資料結構的併發訪問衝突，我們需要鎖或者是訊號量。

理論上來講，這可以對確定的事件提供更好的響應時間。例如，一個特定的按鍵處理消耗30ms 的CPU時間，錄影帶插入處理消耗300ms。操作者插入錄影帶並立即按下按鍵，假使這兩個看起來就像兩個操作者同時操作一樣。開始的50ms時間花費在處理錄影帶插入上。隨後，按鍵處理操作接管了CPU，並完成按鍵處理操作。接下來繼續處理錄影帶操作。如果我們考慮到上下文切換的時間，這兩個任務所需的時間會有所增加。從這點上看，總的消耗時間組成如下：50ms按鍵處理，300ms錄影帶插入，以及兩次上下文切換時間。

然而，從操作者的角度來看，按鍵操作的反饋差不多如同四分之一秒般快速。

在上面的情景中，立即發生的錄影帶插入操作的第一部分響應，通常會給使用者這樣的印象：我的操作被機器識別了。例如，點亮一顆LED

當然，獲得如此好的響應時間也是需要付出代價的。為了保護公共資料以及硬體的共享訪問，需要使用一些軟體保護措施，這將會使得軟體的複雜性大大增加。在採用這些保護措施之前，先要對公共硬體以及資料進行分析，看看是否有太多的重疊操作，以至於任務將會等待同一資源，而這就是瓶頸所在。

在一個通過一個單一螢幕向用戶產生輸出，並且通過操作螢幕來響應其它動作的系統中，系統響應只能等到與螢幕及其相關的資料結構獲取到之後才能產生。在這樣情形下的任一事件處理，在它能夠給使用者任何反饋之前，必須等待前一個事件完成，即便是前一個事件是由另外一個任務控制。因此，所有的工作都是完全的完成，不能夠獲得絲毫好的響應時間。如果對公共硬體以及資料的訪問比較少，則可以獲得一個更好的響應時間，但是這通常會帶來吞吐量的損失。在RTOS