在測試過程中因為會產生不可行競爭變異，因此，我們提出了一個演算法來 對他做可行性檢測，我們稱這個演算法為 filter algorithm，如圖 5.4 所示，filter
algorithm 能夠將競爭分析出來的所有競爭變異進行檢查，將不合適的去除並保留 可行的競爭變異，最後將可行的競爭變異儲存至競爭變異佇列中以供下次前綴重 播作使用。
Filter algorithm 的主要是去模擬執行緒的執行，透過模擬執行過程來判斷是 否為可行的競爭變異，首先我們會創造出一個虛擬的執行環境，包含 entry、waiting、
resurrected、notify set，這裡的 entry set 存放想要且已經獲得 monitor 的同步事件，
waiting set 為存放等待中的重播事件，resurrected set 存放從 waiting set 中被喚醒 準備進入 monitor 的重播事件，notify set 裡的同步事件有權喚醒其他重播事件，
接著我們會將需要檢驗的競爭變異根據全序(totally-ordered)的關係作排序，然後 依序模擬執行全序競爭變異，假設執行過程有可能執行不合理的運算，我們就將 這樣競爭變異判定為不可行的。程式在執行過程中，執行緒會在不同的狀態間轉 換，對同一個共享變數我們分為幾種情況去作討論：
輸入的同步事件 ei為 WAC運算時，若存在另一個同步事件 ei'為 WAC或
WRAC運算在 entry set 中，且與 ei屬於不同執行緒時，則為不可行的競爭 變異。(因為 monitor 一次只允許一個執行緒取得控制權，假設同步事件 ei已經在 entry set 中，表示 ei所屬的執行緒 T 已經取得控制權，若屬於
另一個執行緒 T '的同步事件 ei'再執行 acquire()運算則會造成兩個執行緒
T 和 T '都進入 monitor，明顯違反 monitor 的語義。)
例如：RV0[0]={WAC(S1,1,S0,2,[*,*])},RV0[1]={ WAC(S1,2,S1,2,[*,*])}，如 圖 5.2，P0 獲得 monitor 的使用權後，P1 也會想要獲得，因此，違反 Java
monitor 語義。
輸入的同步事件運算為 WRL時，不會發生不合法的狀況。(只有在還未 取得 monitor 時，才會造成 WRL運算為不合法，然而 acquire()和 release() 必定成對出現且發生在 acquire()之後，因此必已經取得 monitor 的控制 權。)
輸入的同步事件運算為 WWT或 WWTM時，不會發生不合法的狀況。(只 有在還未取得 monitor 時，才會造成 WWT或 WWTM運算為不合法，然而
wait()和 waitTime()必定發生在 acquire()之後，因此必已經取得 monitor
的控制權。)
輸入的同步事件 ei運算為 WRAC時，必須符合以下條件：
Entry set 中不能存在其他屬於不同執行緒的同步事件 ei'。(理由同
運算為 WAC的狀況。)
若 waiting set 中存在一個與 ei相同執行緒的 WWT同步事件 ei'且
notify set 還存在另一個與 ei不同執行緒的同步事件 ei"，則 ei的版本 號必須大於 ei"且 ei"的版本號必須大於 ei'。(這代表同步事件 ei'執行
47
完 wait()運算後，被同步事件 ei"執行 noitfy()運算叫醒，緊接著執行 同步事件 ei的 reacquire()運算回到 owner set 的狀況，因此，版本號 要依序遞增。)
例如：RV1[0]={ WAC(S1,1,S0,2,[*,*]), WWT(S1,2,S0,3,[*,*]),
WRAC(S1,6,S0,5,[*,*])},RV1[1]={ WAC(S1,3,S1,2,[*,*]),
WNTF,P0(S1,4,S1,3,[*,*]), WRL(S1,5,S1,4,[*,*])}，當讀取到 P0 的
reacquire()同步事件 S0,5時，waiting set 存在 P0 的 wait()同步事件 S0,3， notify set 存在 P1 的 notify()同步事件 S1,3，因此，很明顯地同步事件 S0,3的版本號必須大於同步事件 S1,3且同步事件 S1,3的版本號也要大 於同步事件 S0,5的版本號，程式才能正常運行。
若 waiting set 中存在一個與 ei屬於相同執行緒的 WWTM同步事件 ei'，
則 ei的版本號必須大於 ei'。(這是上一條規範的特例，代表同步事件
ei'執行完 waitTime()運算後，過一段時間後會進入 resurrected 狀態，
緊接著執行同步事件 ei的運算回到 owner set 的狀況，因此，ei的版 本號要大於 ei'。)
輸入的同步事件運算為 WNTF或 WNTA時，不會發生不合法的狀況。(原 因同輸入的同步事件運算為 WWT或 WWTM。)
由上述討論可知，filter algorithm 包含所有狀態的轉換，且能將不合理的執行 順序找出來，進而達到過濾的功效。
Algorithm: A race-variant filter to perform feasibility checking
Input: A race variant R that contain six types of synchronization events, acquire, release, wait, waittime, reacquire, notify, and notifyall, which are represented by WAC(U,V,L,C), WRL(U,V,L,C), WWT(U,V,L,C), WWTM(U,V,L,C), WRAC(U,V,L,C), WNOT,P (U,V,L,C), and WNTA(U,V,L,C), respectively.
Output: If R is an infeasible race variant, it returns True. Otherwise, it returns False.
(1) Generate four sets, entry_set, waiting_set, resurrected_set and nofity_set, for each Java monitor which is accessed in R.
(2) Apply topological sort over R to derive an arbitrary totally-ordered sequence of events. Assume that there are n events in R. Let the totally-ordered sequence of events is R′, which have the order e0, e1, …, en-1.
(3) FOR i=0 to n-1, consider the types of synchronization events, there are six cases as following.
Case 1: ei is WAC(U,V,L,C,P)
ELSE IF there is an event ei′ in the resurrected_set of U and belonging to the same thread as ei.
Remove ei′ from the resurrected_set of U and add ei to the entry_set of U.
ELSE IF there is an event ei′, WWT(U,V′,L′,C′,P′), in the waiting_set of U and belonging to the same thread as ei. IF there is an event ei′′, WNOT(U,V′′,L′′,C′′,P′′), in the notify_set of U and belonging to the different thread as ei.
IF V′<V′′<V
Remove ei′ and ei′′ from the waiting_set and notify_set of U, repectively, and add ei to the entry_set
ELSE IF there is an event ei′, WWTM(U,V′,L′,C′,P′), in the waiting_set of U and satisfying the following statements: (1) belonging to the same thread as ei and (2) V′<V.
Remove ei′ from the waiting_set of U and add ei to the entry_set of U.
ELSE
Return False. // ei cannot be executed if the thread is still not resurrected.
Case 5: ei is WNOT(U,V,L,C,P) IF the waiting_set of U is not empty
Add ei to the notify_set of U.
WHILE (1) both the waiting_set of U and the notify_set of U are not empty, and (2) the number of events in the waiting_set of U is equal to the number of events in the notify_set of U.
Randomly pick up two events ei′ and ei′′ from the notify_set of U and waiting_set of U, respectively. // ei′ and ei′′ are not belonging to the same thread.
Remove ei′ from the notify_set of U and move ei′′ from the waiting_set of U to the resurrected_set of U.
Replace ei′ as WNOT(U,V,L,C,T,P) in R.
Case 6: ei is WNTA(U,V,L,C,P) IF the notify_set of U is not empty.
FOR each event ei′ in the notify_set of U. Let ei′ is belonging to the thread T.
Randomly pick up an event ei′′ from the waiting_set of U. Let ei′′ is belonging to the thread T. //
ei′ and ei′′ are not belonging to the same thread.
Remove ei′ from the notify_set of U and move ei′′ from the waiting_set of U to the resurrected_set of U
Replace ei′ as WNOT(U,V,L,C,T,P) in R.
IF the waiting_set of U is not empty.
FOR each event ei′ in the waiting_set of U.
Move ei′ from the waiting_set of U to the resurrected_set of U.
49
(4) Return True.圖 5.4：Java monitor 語義過濾演算法。
我們用圖 5.3 來說明演算法的執行過程，第一步會先建立四個集合，接著，
將圖 5.3 (D)的競爭變異做拓撲排序(typological sort)得到一個全序競爭變異，結果 剛好跟原本的競爭變異相同，第三步我們會依序讀取全序競爭變異中的所有同步 事件，第一個讀到的同步事件為 P9 的 S9,2，因為為 acquire()運算，會判別為 case
1，case 1 中會檢查到 entry set 目前是空的，因此我們將這個同步事件加入 entry set 中，接著繼續讀取下一個同步事件，為 P9 的 S9,3，判別為 case 3，接著會檢查到
entry set 中存在 S9,2同屬於同一個執行緒的同步事件，我們會將 S9,2移出 entry set，
並將 S0,3加入 waiting set，再來會讀取第三個同步事件 S9,4，判別為 case 4，這時 會檢驗四個 IF 判斷式，發現都不符合，最後會傳回 false，判斷為不可行競爭變 異。