The Solutions of Problems

在 4.2.3 節中提到當事件層平行模擬方法整合到 NCTUns 裡會發生的兩個問題，

z 在多核心系統，無法保證應用程式在執行時，模擬引擎並沒有同步執行，使 得模擬時間持繼的進展，造成模擬結果的錯誤。

z 事件層平行方法下，每條 worker threads 都有自己的虛擬時鐘，由應用程式 送出的封包，會先使用 4.3.2 節提到的 tunctl_ec 去通知模擬引擎有新的封包 要從 kernel-level 進入到 user-level，worker threads 會使用函式「readt0e」從 tunctl_ec interface 接收核心傳遞的事件，如果新事件代表的是封包傳輸，

worker threads 會根據自己的虛擬時間，為事件填上開始執行的時間。這樣 的狀況會導致於從 tunctl_ec interface 接收核心傳遞事件的 worker thread 不同，

新事件未來執行的時間也將不一樣。

4.3.1 節中介紹在行程描述器中加入新的欄位「curr_time」去保存每一支行 程的模擬時間，這使得模擬引擎與應用程式都保有自己的時間，即使模擬引擎與 應用程式同步執行，也能保證應用程式的時間能按照自我的行為在跳動，這種作 法可以解決問題 2 所造成的錯誤。問題 2 中，傳輸封包的時間會由讀取 tunctl_ec 的 worker thread 決定，不過，新的方法令應用程式本身就可以填入封包傳輸事件 該發生的時間，所以，不同的 worker thread 去讀取 tunctl_ec 也不會發生模擬的 錯誤。可是，這個條件對於解決問題 1 仍就是不夠的。接著，使用一個簡單的例 子，如 Figure 4.9 描述，突顯使用新的架構下，會出現的問題。

Figure 4.9 Simulation Clock Problem

圖中，存在三條 threads，分別為 worker thread1、worker thread2、master thread，

及兩支應用程式 TCP Sender、TCP Receiver。worker thread1 目前紀錄的時間為 T1，worker thread2 目前紀錄的時間為 T2。worker thread1 在叫醒 TCP Sender 後，

將繼續從安全事件串列中選取另一個安全事件執行，如果目前並無任何安全事件 在安全事件串列中，則 mater thread 會被 worker thread 叫醒，並開始找尋安全事 件，此時 TCP Sender 仍在運算，但是由 TCP Sender 送出的封包在所有的事件串

尋安全事件的過程中，不會發現有這樣的事件存在，使得安全事件的檢測上出現 漏洞，進而造成模擬錯誤。

由此可見，雖然在行程描述器中紀錄了各個行程的模擬時間，應用程式可以 不受到 worker threads 的影響，不過，應用程式和 worker threads 的同步執行，還 是衍生出新的問題。為了解決「flight event」的發生，應用程式執行時，worker threads 必需停止執行，直到應用程式執行結束後，worker threads 才能繼續執行。

相同的例子，當 worker thread1 叫醒 TCP Sender 後，worker thread1 需要拉起重 新排程的旗幟，並從核心排程器的執行佇列中移出，放到等待佇列 (wait_queue)。

TCP Sender 完成封包傳送的工作後，主動叫醒沉睡中的 worker threads，通知它 從 tunctl_ec 裡將新事件搬移至全域事件串列。

worker thread 再叫醒應用程式的同時，會對應用程式的行程描述器資料結構 裡寫入關於把它叫醒的 worker thread 的資訊，包含 worker thread 的模擬時間、

worker thread 的 PID。應用程式結束工作後，會根據行程描述器紀錄的 PID，叫 醒正在等待中的 worker thread。

4.3 The Components of the ELP