之前也整理过一篇文章来说明Oracle Lock的，参考：
锁 死锁 阻塞 Latch 等待 详解
http://blog.csdn.net/tianlesoftware/archive/2010/08/19/5822674.aspx
在这篇文章里，提到了System Locks，它包含：
（1）Latches
（3）Internal Locks
一. 官方文档上关于Mutex 的说明如下
Mutexes
A mutual exclusion object (mutex) is a low-level mechanism that prevents an object in memory from aging out or from being corrupted when accessed by concurrent processes. A mutex is similar to a latch, but whereas a latch typically protects a group of objects, a mutex protects a single object.
Mutexes provide several benefits:
（1）A mutex can reduce the possibility of contention.
Because a latch protects multiple objects, it can become a bottleneck when processes attempt to access any of these objects concurrently. By serializing access to an individual object rather than a group, a mutex increases availability.
（2）A mutex consumes less memory than a latch.
（3）When in shared mode, a mutex permits concurrent reference by multiple sessions.
二. eygle 的blog上搜的信息
Mutex 的发音是 /mjuteks/ ，其含义为互斥(体)，这个词是Mutual Exclude的缩写。
Mutex在计算机中是互斥也就是排他持有的一种方式，和信号量-Semaphore有可以对比之处。有人做过如下类比：
Mutex是一把钥匙，一个人拿了就可进入一个房间，出来的时候把钥匙交给队列的第一个。一般的用法是用于串行化对critical section代码的访问，保证这段代码不会被并行的运行。
Semaphore是一件可以容纳N人的房间，如果人不满就可以进去，如果人满了，就要等待有人出来。对于N=1的情况，称为binary semaphore。一般的用法是，用于限制对于某一资源的同时访问。
对于Binary semaphore与Mutex，这两者之间就存在了很多相似之处：
在有的系统中Binary semaphore与Mutex是没有差异的。
在有的系统上，主要的差异是mutex一定要由获得锁的进程来释放。而semaphore可以由其它进程释放（这时的semaphore实际就是个原子的变量，大家可以加或减），因此semaphore可以用于进程间同步。
Semaphore的同步功能是所有系统都支持的，而Mutex能否由其他进程释放则未定，因此建议mutex只用于保护critical section。而semaphore则用于保护某变量，或者同步。
三. google的其他信息
在Blog搜的信息如下：
http://www.hellodb.net/2010/06/oracle-mutex.html
Latch是Oracle用来在内存中做串行控制的机构，从10g R2开始，Oracle引入了一个新的技术Mutex。Mutex并不是Oracle的发明，而是系统提供的一个底层调用，Oracle只是利用它实现串行控制的功能，并替换部分Latch。
注意这里是部分替代：
Lateches can't be replaced by Mutex and Mutex are not replaced by latches. latches have more functionality than mutex. It is like enqueue is big ompared to lateches, lateches bigger than mutex. each and every low level serailaization device is seperate and have seperate roles.
Mutex是操作系统为了实现PV操作提供的原子功能，P/V两个操作都必须是原子的，才能保证并发不被打乱，与其相似的还有信号量Semaphore，这些都是操作系统原理上的东西了
Mutex中有两个变量：分别是Holider identifer和Reference count，Holider identifer记录持有mutex的SID，而Reference count是一个计数，记录了当前正在以share方式访问mutex的数量，每当session以share方式持有mutex时，计数会加1，而释放时会减1。如果Reference count大于零，则表示该内存结构正在被Oracle pin住。
我们看一段伪代码，演示mutex的申请过程：
Function Mutex_get(mutex_name)
{
if mutex.holder:=SID
case mode:
'exclusive':
if mutex.ref_count=0
return TRUE
else
mutex.holder.clear;
reture FALSE
end if
'share':
mutex.ref_count++
mutex.holder.clear
return TRUE
end case
else
reture FALSE
end if
}
Mutex是如何实现串行控制的，实际上它是利用了操作系统的一个原子操作CAS(compare-and-swap)实现的。
我们看到函数的开始处：mutex.holder:=SID，将SID赋值给mutex的Holider Identifer，这里就是一个原子的CAS操作，首先比较mutex.holder是否为空，如果不为空则赋值session的SID。CAS操作由OS来保证其原子性，在同一时刻这个操所是串行的。
如果这个赋值操作失败，整个申请过程失败。赋值成功后，如果是share方式，则mutex.ref_count加1，并清空mutex.holder，如果是exclusive方式，需要判断mutex.ref_count是否为零（是否被pin住），如果大于0，则失败，并清空mutex.holder，如果等于0，则成功，这时不清空mutex.holder，保持当前session对mutex的exclusive占用，直到释放为止。
Mutex相比latch带来了以下的好处：
1.更少的资源消耗，mutex与latch不同，它不是独立存在的，而是在每个内存结构中，并随着内存结构创建和释放，mutex同时也被创建和释放。mutex暂用的空间比latch小很多，创建和释放消耗更少的资源。
2.有效降低竞争，因为mutex是每个内存结构中的一部分，这样意味着mutex的数量可以有很多，而不同于latch，一个latch需要管理很多个内存结构，当你访问同一latch管理的不同内存结构时，也会发生竞争，而mutex则不会。
另外，因为latch的数量有限，很多时候latch本身的竞争会很厉害，之前，我们只能增加latch数量或者减少latch持有的时间，而现在，mutex是一个更好的选择。
3. 更快的pin，当block被访问时，它必须被pin在buffer cache中，当一个cursor执行时，它也必须被pin在library cache中，如果大量并发频繁执行同一个cursor，library cache pin会耗费大量的CPU资源。
而mutex使用reference count来解决并发访问的问题，只要它大于零，就表示它已经被pin在了内存中，不能被交换出去。而且mutex.ref_count++这个操所是非常快的，只占用非常少的资源。
Mutex申请的过程和latch类似，同样需要spin和sleep，不同的是Oracle硬编码了mutex spin的次数为255次（Latch spin的次数默认为2000，由隐含参数_spin_count控制）。
latch sleep会随着等待次数的逐步增加，每次sleep的时间也会逐步增加。 mutex sleep则比较特别，它有三个选项，分别是yield CPU，sleep或者block other process，允许开发人员来决定采用哪种选项。
由于在某些RISC的操作系统中（HP-UNIX），由于系统不支持CAS操作，Oracle通过创建一个latch pool来模拟了CAS操作，被称为KGX latch，如果你发现系统中存在这种latch竞争，说明操作系统不支持CAS操作，可以通过_kks_use_mutex_pin关闭mutex。
mutex主要使用在library cache中，用来取代原来的library cache pin和library cache lock。
KGX mutexes are not OS mutexes, ORACLE KGX Mutex 同样是基于spinlock构建.
Data 1：
things get more fun in 10.2, you can pin cursors without getting library cache pin latch, using KGX mutexes. Mutexes are new in 10.2 and they enable shared access to objects in somewhat similar manner to shared latche; every successful get of a particular mutex will increment its value and a release will decrement. When the count is zero, no one has the mutex and it is safe to get it in exclusive mode. However, they are more fine-grained than kgl latches and provide a better wait mechanism, as far as I understand.
So if your environment supports atomic compare and swap operation (such as CMPXCHG on Intel), you might get away without cursor_space_for_time setting for ultrahigh execution rates. Otherwise the atomic mutex operations would be achieved using the new KGX latches.
At least on my laptop this feature isn't enabled by default (from an OracleWorld paper I remember that it should become default in 10.2.0.2), but so far you can experiment with it if you set _kks_use_mutex_pin = true and bounce the instance (mutex structures will be stored in the shared pool, so you might need to increase shared pool size).
There are also X$MUTEX_SLEEP and X$MUTEX_SLEEP_HISTORY fixed tables that can show some interesting information if you generate some mutex waits into them.
Data 2：
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.
2.1 Serialization is required to avoid an object being:
（1） Deallocated while someone is accessing it
（2） Read while someone is modifying it
（3） Modified while someone is modifying it
（4） Modified while someone is reading it
2.2 Mutexes can be defined and used in different ways, as in the following examples:
（1）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)
（2）Each structure can be protected by more than one mutex, with each mutex protecting a different part of the structure.
（3） A mutex can protect more than one structure.
2.3 Although mutexes an latches are both serialization mechanisms, mutexes have certain features that latches do not:
（1）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.
（2） Less Potential for False Contention
Latch typically protect multiple objects. When a latch 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 be 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.
（3）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) mode 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.
2.4 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:
（1）V$MUTEX_SLEEP shows a summary of sleeps and wait time for particular mutex_type/location combination.
SQL>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
（2）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.
2.5 Mutex wait event have two categories:
（1）cursor:mutex indicates that the mutex waits on parent cursor operations and statistics block operations.
（2）cursor:pin events are wait for cursor pin operations, where a mutex has replaced the latch:library cache pin.
2.6 Mutex wait events are of two types
（1）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.
（2） 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.
2.7 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-protected operations is significantly faster than latched operations. The child cursor lists are protected by mutexes.
小结：
这些资料先是看了一遍，然后整理了一篇。 感觉还是有点没吃透。 Oracle 内存这块的东西还需要深入研究。 先这样吧。以后有新理解的时候在修改。
-------------------------------------------------------------------------------------------------------
Blog： http://blog.csdn.net/tianlesoftware
Email: dvd.dba@gmail.com
DBA1 群：62697716(满); DBA2 群：62697977(满) DBA3 群：62697850(满)
DBA 超级群：63306533(满); DBA4 群： 83829929 DBA5群： 142216823
DBA6 群：158654907 聊天 群：40132017 聊天2群：69087192
--加群需要在备注说明Oracle表空间和数据文件的关系，否则拒绝申请