答案 (D)。(D)正確的原因：Mutex lock的基本協定就是在進入critical section（更新共享記憶體）前執行acquire()取得鎖、離開時執行release()釋放鎖。更關鍵的是「mandatory」（強制性）這個前提——在一般的建議性鎖定（advisory locking）下，鎖的保護完全仰賴所有行程自律配合，若有行程沒取得鎖就直接寫入共享記憶體，作業系統並不會阻止，此時無法真正保證mutual exclusion；只有當鎖被系統實作為強制性（mandatory），作業系統才會在存取層面強制攔截未持有鎖的存取，這樣才能真正「確保（guarantee）」mutual exclusion，(D)敘述完整描述了這個條件。

(c)為何錯誤：題幹明確要求「共享的記憶體變數由critical section保護以避免並行更新」，critical section的核心要求正是mutual exclusion；若允許一個以上的行程同時更新共享變數，會直接引發race condition導致資料不一致。雖然counting semaphore的初始值確實可以設為大於1，但那是用來管理「多個可用資源實例」或支援「多個行程同時讀取」的情境；在保護共享變數避免並行更新的情境下，必須使用binary semaphore（值僅0或1），不允許一個以上的行程同時進行更新，因此(c)在這個情境下不是正確描述。

(a)錯：memory barrier只保證記憶體操作的順序性（ordering），不提供mutual exclusion機制本身。(b)錯：單純「atomic的load與store」不足以保護跨越多個陳述式的critical section（需要像compare-and-swap這類atomic read-modify-write，才能真正防止並行更新）。