Can you summarize the following document?
        
  依實現方式可分為硬體實現和軟體實現兩種。

  單核心繫統上最常見的方式就是關閉儘可能多的可能對共享資料段進行讀寫的指令中斷。這樣一來就可以避免在臨界區域中暫停程式執行,或是來自硬體的要求修改目標共享資料段的中斷請求。多核心繫統上則通過檢查並置位(獲取原始值並指定新值)機制達成,當一個核心需要另一個核心佔用的資源的時候,該核心將不斷的查詢所有核心間共享的佔用旗標,直到另一個核心將佔用旗標復位為未使用為止。相關的虛擬碼如下所示: lock的值為1則表示鎖被佔用,為0則是空閒。  在檢查並置位機制中,一個核心在對旗標執行讀寫的過程當中不會釋放佔用的訪問匯流排。該種方法又稱為自旋鎖。  類似的原子操作,如比較並交換機制,則更常用於對連結串列等資料結構進行不阻斷同步。

  類似的方式也有通過軟體模擬達成的。但是該種模擬會對計算機造成極大的負荷,因為申請佔用自旋鎖的過程中會不間斷地對一個標誌位進行讀寫,並且該種模擬不允許亂序執行,因為這會破壞其機制。  更為常見的是使用作業系統提供的互鎖庫,這種庫通常設計為在有硬體支援時使用硬體機制,僅在找不到支援的硬體時才用軟體模擬,並且結合執行緒排程對鎖效能進行優化。比如一個執行緒要使用一個已經被佔用的鎖,這時候作業系統會把這個執行緒掛起,然後進行context switching到另外一個可以繼續執行的執行緒,若是沒有別的執行緒要繼續執行的話,系統就讓處理器進入低功耗狀態,而不是讓這個執行緒消耗大量處理能力進行自旋來等待鎖釋放。  現代的互斥鎖大多使用佇列和上下文切換以達到節約資源和降低延遲的目的。但是總有些情況下,掛起一個程序,然後過一陣子再恢復所用的時間會比讓程序在那裡自旋等待用的時間長。在這種情況下則更多會使用自旋鎖。

  除了上述的基礎互斥鎖,還有一些更高階的實現方式,如: 這些鎖各有各的副作用。例如一個常見的訊號標會允許死鎖的發生(兩條執行緒各自獲取了一個訊號標,然後都在等待對方釋放另外一個)。其他可能會出現的現象有優先順序倒置(高優先順序的程式等待低優先順序的程式完成)、資源饑荒(某個執行緒一直得不到足夠的鎖資源)等。  目前的研究多側重於消除這些副作用上,例如不阻斷同步,但是並沒有完美的解決方案。

  Windows作業系統提供了mutex同步物件。它有兩個狀態:  Windows API函式CreateMutex或CreateMutexEx建立mutex物件。使用OpenMutex函式開啟一個mutex物件。也可以使用DuplicateHandle函式或者父子handle繼承來使用一個無名mutex物件。  任何執行緒可以使用mutex的控制代碼(handle)於等待函式(wait functions)來獲得這個mutex物件的擁有權。如果該mutex物件正被其他執行緒擁有,則請求的執行緒在該等待函式上被阻塞直到擁有的執行緒呼叫ReleaseMutex函式釋放mutex並被該請求執行緒獲取到擁有權。等待函式的返回值可以鑑別是否獲得了擁有權(該mutex被signaled)或者其他原因(如超時返回).  如果多個執行緒正在等待一個mutex物件,那麼該mutex被signaled時喚醒哪一個執行緒不能保證遵循先進先出(FIFO)順序。外部事件如非同步過程呼叫可改變等待順序。  如果一個執行緒擁有了一個mutex物件,該執行緒可以對該mutex物件執行多次等待函式呼叫而不會被阻塞。釋放mutex物件時,該執行緒必須呼叫ReleaseMutex函式的次數必須與呼叫等待函式的次數相同。 mutex物件內部有一個遞迴計數,表示獲得了該物件的執行緒佔用該物件的次數。  擁有mutex物件的執行緒沒有釋放擁有權就結束了,那麼該mutex物件被放棄(abandoned). 等待該mutex物件的其他執行緒可獲得擁有權,但從等待函式得到的返回值為WAIT_ABANDONED。這表示一個錯誤已經發生了,任何被該互斥鎖保護的共享資源處於未定義的狀態。  Windows作業系統的臨界區(critical section)物件類似於mutex物件,但是臨界區物件只能用於一個程序內部。
互斥鎖(英語:Mutual exclusion,縮寫 Mutex)是一種用於多執行緒程式設計中,防止兩條執行緒同時對同一公共資源(比如全域變數)進行讀寫的機制。該目的通過將程式碼切片成一個一個的臨界區域(critical section)達成。臨界區域指的是一塊對公共資源進行存取的程式碼,並非一種機制或是演算法。一個程式、程序、執行緒可以擁有多個臨界區域,但是並不一定會應用互斥鎖。