2. 文獻探討 文獻探討 文獻探討 文獻探討
2.2 Dynamic Effective Testing
雖然 reachability testing 已實證能完整地測試並行程式的非決定性行為，並 在效能上取得長足的進步，但其基礎架構上卻存在一種嚴重的不足。在前面提到，
reachability testing 在 monitor 的過程中並不對受測程式的執行進行任何干預，因 此當程式中出現無窮迴圈或忙碌等待迴圈(busy-waiting loops)時，reachability
e2 E
Reverse direction of in-edges Remove some nodes
There is a loop.
P0 P1
testing 很容易因為執行無法順利結束，導致 prefix-based replay 的過程中失敗。
“a” is a shared variable.
Process 0 Process 1
S0,2, …}是其中一個可能產生的執行順序。就如前面所敘述 reachability testing 的 架構，執行時產生的順序將會被記錄下來，提供後續的 race analyzer 作分析的動
作；但在以{S0,0, S1,0, S0,1, S0,2, …}為首的執行順序時，程式將會進入無窮的
等待迴圈之中，不斷地記錄的執行順序，最終耗盡系統所有可用的記憶體空間。
“a” is a shared variable and its initial value is 0.
Process 0 Process 1
受測程式最快可能只執行三行的程式碼{S1,0, S0,0, S0,1}就結束，也有可能多在迴
圈裡執行一次，得到{S0,0, S0,1, S1,0, S0,0, S0,1}這樣的執行順序。很明顯地，process
0 中的迴圈 S0,0, S0,1必須不斷地執行忙碌等待迴圈直到 process 1 中的 S1,0獲得執 行；有別於無窮迴圈的例子最終必定會因為操作系統排程給 process 1 而執行結
束。但是在 reachability testing 的架構之下，race analyzer 為達到完整測試的目的，
會將所有程式可能的執行順序全部產生，因此無論是執行迴圈 S0,0, S0,1 一次、
兩次，甚至是無限多次的執行順序，都會因為 race analyzer 視作相異的 race
variants 而逐一地付予執行。我們可以把這些產生的 race variants 表達成{(S0,0,
S0,1,)i S1,0, S0,0, S0,1}的形式，其中 i 可以是大於或等於零的任意整數，而這些 race
variants 將使得存放 race variants 的佇列永遠無法被清空，整個 reachability testing 將因而沒有結束的時候。
前面以一個最簡單的例子說明非無窮迴圈可能的問題，其中反覆執行的部分
S0,0, S0,1都在同一個程序中。另一個較複雜的例子，反覆執行的部份將橫跨兩個 不同的程序。在圖.7 造成 Reachability testing 問題的受測程式之三中最短的可能
執行序列是{S1,0, S0,0, S0,1, S1,1}，和前述例子類似，這個例子中所有可能的執行
序列可以表達成：{(S0,0, S1,0, S0,1, S1,1,)i S1,0, S0,0, S0,1, S1,1}，其中 i 是大於或等
於零的任意整數；可能重複執行的部分為 S0,0, S1,0, S0,1, S1,1，分別屬於 process 0
與 process 1。
“a” is a shared variable.
Process 0 Process 1
...
S0,0 DO { a = 1;}
S0,1 WHILE(a==0)
...
...
S1,0 DO { a = 0;}
S1,1 WHILE(a==0)
...
圖.7 造成 Reachability testing 問題的受測程式之三
Multi-thread 系統的測試驗證有以下困難點： Shared variables 的存取造成
race condition 除了、具迴圈，還有 Task priority，分成以下三個部分來進行研究：
處理迴圈程式可能造成的問題，在 prefix-based replay 時要能將已陷入無窮迴圈
的受測程式強制結束，並回報可能造成無窮迴圈的部分程式碼與特定的執行順序
。其次，在 race analyzer 的部分應發展能處理忙碌等待迴圈的演算法，避免產出
過多的 race variants，導致無窮的測試。