Mutex(測)，mutex

Mutex(測)，mutex
遊標共用如何使用Mutex

kks 使用mutex以便保護對於下述基於parent cursor父遊標和子遊標child cursor的一系列操作

對於父遊標parent cursor的操作：

• 基於發生的不同操作，對應不同的等待事件：
  • 在某個父遊標名下建立一個新的遊標                     ==> cursor:mutex X
  • 檢查一個父遊標                                                              ==> cursor:mutex S
  • 綁定值捕獲                                                                    ==> cursor:mutex X
• 保護父遊標的mutex嵌入在父遊標結構內
• 針對父遊標parent cursor的Mutex類型為’Cursor Parent’ (kgx_kks2).
•  針對父遊標parent cursor的Mutex等待事件均為’ Cursor: mutex *’的形式

Mutex是如何替代library cache pin來保護cursor heap的？

• 傳統的’library cache pin’在10.2.0.2之後預設被取代， 此處PIN被Mutex及其ref count取代。 當進程執行遊標語句時或者需要PIN，或者需要hard parse一個子遊標heap。
• 在版本10.2.0.1中， 使用mutex部分代碼替代PIN的功能預設是不啟用的，實際上這取決於隱藏參數_KKS_USE_MUTEX_PIN，在10.2.0.2之後_KKS_USE_MUTEX_PIN預設為TRUE。 換而言之在版本10.2中我們還是可以關閉KKS使用MUTEX替代PIN保護CURSOR的， 但是在版本11g中則幾乎無法關閉MUTEX。 注意10.2中僅當KKS真正使用MUTEX時，library cache pin不再用作cursor pin。
• 基於對不同的遊標統計資訊的操作有不同的等待事件：
  • 為執行某個SQL而PIN一個遊標Cursor                        ==>Cursor: Pin S Wait on X
  • 當執行一個遊標而PIN Cursor，而該Cursor正被其他進程以S mode檢測             ==>  cursor:pin S
• 當試圖重建一個遊標Cursor  ==> Cursor: pin X  該等待事件一般不太會看到，因為當一個遊標正被執行，且其需要重建時會有另一個遊標被建立
• 保護遊標的mutex嵌入在遊標結構內
• Mutex類型為’Cursor Pin’ (kgx_kks3)
• 等待事件均為 ‘cursor: pin *’的形式

KKS使用MUTEX情況下SQL語句的 解析與執行的收益

在版本10.2中， 以下是幾個SQL解析與執行從MUTEX哪裡獲得主要收益：

• 在某個父遊標下構建一個新的子遊標
  • 首先這種構建新子遊標的操作更廉價了，  當時Maclean仍要告誡你 一個父遊標下過多的子遊標仍不是一件好事情
• 對父遊標的檢測
  •  在找到一個合適的遊標並執行前，父遊標需要被適當檢測。 對父遊標的這種檢測目前也使用mutex來保護了，所以這種檢測更的成本更低了
• 對於已經載入在Library Cache 中的SQL語句重複執行
  • 常規情況下，當一個進程要執行SQL遊標前總是必須要先pin它
  • 不使用MUTEX的情況：若遊標處於OPEN狀態下以便今後的重複執行，且參數cursor_space_for_time(CSFT  目前已不推薦使用該參數)為TRUE，則每一次重複執行可以不需要library cache pin。 若遊標處於OPEN狀態下但是cursor_space_for_time=false，則進程在重複執行SQL遊標前總是要先拿library cache pin
  • 使用MUTEX的情況: 相反，若使用mutex來替代library cache pin時，則無需關心cursor_space_for_time 。 僅第一個進程需要做一個PIN他後續進程都只需要簡單地在對應保護cursor heap的mutex上拿一個共用reference 。

真正理解Mutex相關的等待

Mutex資料結構中存放了Holder id持有人ID ， Ref Count，和其他Mutex相關的統計資訊。 Holder id對應於持有該Mutex的session id (v$session.sid)  。特別注意， Ref Count是進程並發以S mode參考該Mutex的進程數量。

當一個Mutex被以X mode 持有，則Holder id 為對應持有該mutex的session id，而Ref Count為0。

每一個共用S mode持有人僅僅增加mutex上的Ref Count。 可供大量session並發以S mode持有參考一個Mutex。 但是注意更新ref count的操作是串列的， 這是為了避免錯漏並維護mutex中正確的ref count。

下面我們詳細介紹一個執行遊標過程中對mutex share pin的過程：

• 某進程以SHRD 模式申請一個Mutex，並嘗試臨時修改該Mutex的Holder ID
• 若該Mutex正被他人更新，則該session會將Holder id設定為本session的sid，之後該進程將增加ref count，之後再清楚mutex上的Holder id。簡單來說 這個Holder id是真正做了並行控制的功能。 若該Holder id 被設定了，則說明該Mutex要麼被以EXCL模式持有，要麼正有一個其他進程在以S mode申請該Mutex的過程中(例如更新Ref Count)。當更新Ref Count時臨時設定holder id的目的就是為了實現避免其他進程並發更新該Mutex的機制。 通過這些例子說明了 , Mutex既可以用作Latch並發控制， 也可用作pin。
• 若Holder id已被設定，則申請進程將可能進入等待事件 。  例如若當前Mutex的持有人進程正以X mode更新該Mutex，則申請者的等待事件應為”cursor: pin S on X” 。  而若當持有人Holder並不是”真的要持有” 該Mutex，而僅僅是嘗試更新其Ref Count,則第二個進程將等在’ Cursor :pin S’等待事件上； 實際正在更新Ref count的操作時很快的，是一種輕微的操作。 當第一個進程正在更新mutex，則後續的申請進程將進入spin 迴圈中255次等待前者結束。 當mutex上不再有 Holder id時(如前者的進程已經更新完Ref Count)時， 則申請者進程將Holder ID設為自身的SID，並更新Ref Count，並清除Holder id。 若在255次迴圈SPIN後mutex仍不被釋放，則該進程進入等待並不再跑在CPU上。

Mutex的相關統計視圖

V$MUTEX_SLEEP

shows the wait time, and the number of sleeps for each combination of mutex type and location.

Column	Datatype	Description
MUTEX_TYPE	VARCHAR2(32)	Type of action/object the mutex protects
LOCATION	VARCHAR2(40)	The code location where the waiter slept for the mutex
SLEEPS	NUMBER	Number of sleeps for this MUTEX_TYPE and LOCATION
WAIT_TIME	NUMBER	Wait time in microseconds

V$MUTEX_SLEEP_HISTORY

displays time-series data. Each row in this view is for a specific time, mutex type, location, requesting session and blocking session combination. That is, it shows data related to a specific session (requesting session) that slept while requesting a specific mutex type and location, because it was being held by a specific blocking session. The data in this view is contained within a circular buffer, with the most recent sleeps shown.

Column	Datatype	Description
SLEEP_TIMESTAMP	TIMESTAMP(6)	The last date/time this MUTEX_TYPE and LOCATION was slept for by theREQUESTING_SESSION, while being held by the BLOCKING_SESSION.
MUTEX_TYPE	VARCHAR2(32)	Type of action/object the mutex protects
GETS	NUMBER	The number of times the mutex/location was requested by the requesting session while being held by the blocking session. GETS is only incremented once per request, irrespective of the number of sleeps required to obtain the mutex.
SLEEPS	NUMBER	The number of times the requestor had to sleep before obtaining the mutex
REQUESTING_SESSION	NUMBER	The SID of a session requesting the mutex
BLOCKING_SESSION	NUMBER	The SID of a session holding the mutex
LOCATION	VARCHAR2(40)	The code location where the waiter slept for the mutex
MUTEX_VALUE	RAW(4)	If the mutex is held in exclusive (X) mode, this column shows the SID of the blocking session, else it shows the number of sessions referencing the mutex in S mode.
P1	NUMBER	Internal use only
P1RAW	RAW(4)	Internal use only
P2	NUMBER	Internal use only
P3	NUMBER	Internal use only
P4	NUMBER	Internal use only
P5	VARCHAR2(64)	Internal use only.

askmaclean 主要來源！  

Mutex的用法問題，指點

不建議將Mutex放在執行個體對象中，也不建議放在建構函式中。執行個體對象被GC回收、或執行個體對象創造的局部變數被GC回收將會導致可以再次運行。
你這裡的代碼是因為Mutex屬於局部變數，因此會在構造完成後不定時地被GC回收。
建議將檢測代碼放在Program.cs中的Main方法中，在Application.Run之前。
 
問c語言if(mutex==0)是表示什意思

絕對有這個函數的定義的,你可以在VC裡編譯下試試,在變數上點右鍵可以尋找聲明
mutex有可能是個互斥器變數,我記不太清楚怎麼用了,一般是用來表示一個視窗或變數,只能產生一個
==0就是表示還沒有執行個體產生