Mutex is the short form mutual exclusion object.
A mutex, similar to a latch, is a low-level serialization mechanism used to control access to a shared data structure in the SGA.
Serialization is required to avoid an object being:
- Deallocated while someone is accessing it
- Read while someone is modifying it
- Modified while someone is modifying it
- Modified while someone is reading it
Mutexes can be defined and used in different ways, as in the following examples:
- Each structure being protected by a mutex can have its own mutex (for example, a parent cursor has its own mutex, and each child cursor has its own mutex)
- Each structure can be protected by more than one mutex, with each mutex protecting a different part of the structure.
- A mutex can protect more than one structure.
Although mutexes an latches are both serialization mechanisms, mutexes have certain features that latches do not:
- Smaller and Faster
Mutexes are an alternative to latches because they are smaller and much faster to get. A mutex get uses fewer instructions compared to a latch get. A mutex takes less memory space compared to a latch.
- Less Potential for False Contention
Latch typically protect multiple objects. when a latach protects one or more hot objects, the latch itself can become a serialization point when accessing any of the objects protected by that latch. This can b e a false contention point, where the contention is for the protection mechanism (that is, latch), rather than the target object you are attempting to access. Unlike latches, with mutexes it is possible to create mutex for each structure protected. this mean that false contention is much less likely because each structure can be protected by its own mutex.
- Replace Latches and Pins
A mutex can be concurrently referenced by many sessions, providing all sessions reference the mutex in S (Shared) mode. The total number of sessions referencing a mutex in S mode is called the reference count (”ref count”). The ref count for a mutex is stored within the mutex itself. A mutex can also be held in X (eXclusive) ode by one session only.
Mutexes have a dual nature; they can act as a serialization mechanism (for example, latch) and also as a pin (for example, preventing an object from aging out). For example, the ref count of a mutex is a replacement for a library cache pin. Instead of each session creating and then deleting a library cache pin when executing a cursor, each session increments and decrements the ref count (so the ref count replace n distinct pins).
Note: Latches and mutexes are independent mechanisms, that is, a process can hold a latch and a mutex at the same time.
Mutex operations are faster and have less contention than latches, but mutex operations still have waits associated with them. Two V$ view provide detail of mutex sleeps:
- V$MUTEX_SLEEP shows a summary of sleeps and wait time for particular mutex_type/location combination.
select * from v$mutex_sleep;
MUTEX_TYPE LOCATION SLEEPS WAIT_TIME
——————————– —————————————- ———- ———-
Cursor Stat kksIterCursorStat [KKSSTALOC6] 103 163
Cursor Stat kksFindCursorStat [KKSSTALOC3] 23157 36724
Cursor Parent kksfbc [KKSCHLCREA] 1799 10170
Cursor Parent kkspsc0 [KKSPRTLOC27] 26 627
Cursor Parent kkspsc0 [KKSPRTLOC26] 122 2872
Cursor Parent kkshbbr [KKSPRTLOC15] 660 1779
Cursor Parent kksLoadChild [KKSPRTLOC4] 1181 6932
Cursor Parent kksfbc [KKSPRTLOC2] 9006 34053
Cursor Parent kksfbc [KKSPRTLOC1] 2831 144439
Cursor Pin kksLockDelete [KKSCHLPIN6] 5021 1055990
Cursor Pin kkslce [KKSCHLPIN2] 265549 2792810468
Cursor Pin kksfbc [KKSCHLPIN1] 1203 5132409
Cursor Pin kksfbc [KKSCHLFSP2] 9279 56902065
- V$MUTEX_SLEEP_HISTORY show sessions sleeping for a particular mutex_type/location combination by time while it is held by a specific holding session.
Mutex wait event have two catagories:
- cursor:mutex indicates that the mutex waits on parent cursor operations and statistics block operations.
- cursor:pin events are wait for cursor pin operations, where a mutex has replaced the latch:library cache pin.
Mutex wait events are of two types:
- Short-duration events that should rarely be seen. These occur when one process attempts to update the mutex while it is being changed by another process. The waiting process will spin waiting for the mutex to be available. For example, cursor:pin S is incremented when another process is updating the reference count(pin) of shared cursor.
- Long-duration events occur when a process must wait for other processes to finish their operation. For example, cursor:mutex X is incremented when a process wants an exclusive access but the mutex is being held exclusive or shared by another process.
Mutex-Protected Operations:
A mutex is another protection mechanisms that can protect critical operations. From Oracle database V. 10.2.0.2 and later, a SELECT from the V$SQLSTATS view is protected by mutexes. The use of mutex-protectd operations is significantly faster than latched operations. The child cursor lists are protected by mutexes.
.text:''):(d.getSelection?d.getSelection():'');void(keyit=window.open('http://my.poco.cn/fav/storeIt.php?t='+escape(d.title)+'&u='+escape(d.location.href)+'&c='+escape(t)+'&img=http://www.h-strong.com/blog/logo.gif','keyit','scrollbars=no,width=475,height=575,status=no,resizable=yes'));keyit.focus(); "添加到 POCO 网摘"){kind=logo}
