原文转自：http://www.hellodb.net/2010/06/oracle-mutex.html   http://blog.csdn.net/tianlesoftware/article/details/6455517

在这篇文章里，提到了System Locks，它包含：

（1）Latches

（2）Mutexes

（3）Internal Locks

一.  官方文档上关于Mutex 的说明如下

Mutexes

A mutual exclusion object (mutex) is a low-level  mechannism 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（和latch类似）, but whereas（然而） a latch typically protects a group of objects, a mutex protects a single object.（一个latch保护一组对象，一个mutex保护一个对象）

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.(mutex有效的减少了竞争，因为latch保护的是多个对象，在访问这些对象的时候就会形成瓶颈，但是mutex只保护一个对象，这样大大提高了资源可用性)

（2）A mutex consumes less memory than a latch.(mutex占用的内存资源比latch少)

（3）When in shared mode, a mutex permits concurrent reference by multiple sessions.(共享模式下的mutex，允许并发进程访问数据)

二.  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则用于保护某变量，或者同步。

最近有客户在Oracle10gR2上遇到了Mutex竞争的问题。

Mutex是Oracle在Oracle10g中引入的串行机制，逐渐会用来替代一些存在性能问题的Latch。
和Latch相比，一个Mutex Get大约仅需要30～35个指令，而Latch Get则需要大约150～200个指令，同时在大小上，每个Mutex仅占用大约16 Bytes空间，而一个latch在10gR2中要占用大约112 Bytes空间。

Mutex首先替代了Library Cache Latch以及Library Cache Pin，在Oracle 10.2.0.2上通过隐含参数_kks_use_mutex_pin的调整可以限制是否使用Mutex机制来实现Cursor Pin：

SQL> set linesize 120
SQL> col name for a30
SQL> col value for a20
SQL> col describ for a60
SQL> SELECT x.ksppinm NAME, y.ksppstvl VALUE, x.ksppdesc describ
  2    FROM SYS.x$ksppi x, SYS.x$ksppcv y
  3  WHERE x.indx = y.indx
  4    AND x.ksppinm LIKE '%&par%'
  5  /
Enter value for par: mutex
old  4:    AND x.ksppinm LIKE '%&par%'
new  4:    AND x.ksppinm LIKE '%mutex%'

NAME                    VALUE                DESCRIB
------------------ -------------- ------------------------------------------------------------
_kks_use_mutex_pin      TRUE            Turning on this will make KKS use mutex for cursor pins.

在新的Mutex Pins机制下，以下等待事件可能变得常见：
cursor: mutex S
cursor: mutex X
cursor: pin S
cursor: pin S wait on X
cursor: pin X 

由于Mutex使用CAS（Compare and Swap）机制，所以在不支持CAS的HP Unix平台上就可能出现CPU消耗过高的情况。
这作为一个Bug在10.2.0.4版本中被修正。

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.

我们都知道Latch是Oracle用来在内存中做串行控制的机构，从10g R2开始，Oracle引入了一个新的技术-Mutex。Mutex并不是Oracle的发明，而是系统提供的一个底层调用，Oracle只是利用它实现串行控制的功能，并替换部分Latch。

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:=SIDcase mode:'exclusive':if mutex.ref_count=0return TRUEelsemutex.holder.clear;reture FALSEend if'share':mutex.ref_count++mutex.holder.clearreturn TRUEend caseelsereture FALSEend 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，关于library cache中锁的实现机制，我会在另外一篇文章中说明。