Latches are the more restrictive mechanism, because they do not allow multiple
processes to inspect the protected data structure at the same time—they provide
for exclusive access only.[1] Locks allow for better concurrency, because they may
be held in a shared mode when the data structure is simply being inspected.
[1] This is a simplification. The redo copy latches can be shared, but this is hardware
dependent.
Another significant difference between locks and latches is request queuing.
Requests for locks are queued if necessary and serviced in order, whereas latches
do not support request queuing. If a request to get a latch fails because the latch
is busy, the process just continues to retry until it succeeds. So latch requests are
not necessarily serviced in order.
Because a latch can only be held by one process at a time, and because there is no
inherent concept of queuing, the latch data structure itself is very simple—
essentially just a single location in memory representing the state of the latch.
And because the latch data structure is so simple, the functions to get and release
a latch have very little work to do. By contrast, the data structures for locks are
much more sophisticated because of their support for queuing and concurrency.
So the functions to get, convert, and release locks have correspondingly more
work to do.
Of course, it is necessary for Oracle to ensure that only one process at a time can
modify the latch and lock data structures themselves. For latches this is easy.
Because each latch is just a single location in memory, Oracle is able to use the
TEST AND SET, LOAD AND CLEAR, or COMPARE AND SWAP instructions of
the underlying hardware's instruction set for its latch get operations. Because
these are simple machine instructions that are guaranteed to be atomic, no other
locking mechanism is needed. This simplicity makes latch gets very efficient.
Oracle's lock data structures, on the other hand, have several parts, and therefore
cannot be modified atomically. For this reason, Oracle actually protects operations
on locks with latches. The type of latch used varies depending on the type of lock.
For example, the cache buffer locks are indirectly protected by the cache buffers
chains latches, and the row cache enqueue locks are protected by the row cache
objects latch.

明白了 “cursor：pin S和cursor：pin X相当于share和exclusive类型的library cache pin，cursor：pin S wait on X则表示share方式正在等待exclusive锁定” 的含义：
cursor：pin S 相当于share类型的library cache pin
cursor：pin X 相当于exclusive类型的library cache pin，
cursor：pin S wait on X 则表示share方式的library cache pin正在等待exclusive锁定

Library cache lock有三种模式：null，share，exclusive，Library cache pin有两种模式：share，exclusive。

其它有一些地方说：Library cache pin 也有三种模式：null，share，exclusive。
比如：http://www.eygle.com/archives/20 ... ache_pin_grant.html

到底该如何理解呢？

仔细读完之后，颇有收获。但是有两点不太明白：
1）SQL1: select * from emp;SQL2: select * from emp和select a.name from emp a,dept b where a.dept_id=b.id and b.name=:1;SQL1产生了两个子游标，也就是SQL文本相同的两个不同版本，他们同时依赖emp表。SQL2只有一个版本，因为每个游标最少有一个子游标，所以它只有一个子游标，并且同时依赖dept表和emp表。

2）从Oracle10g开始，Oracle正在逐步用mutex取代library cache中的latch，cursor：pin S和cursor：pin X相当于share和exclusive类型的library cache pin，cursor：pin S wait on X则表示share方式正在等待exclusive锁定。（这段话完全读不明白。）

还相老师和各位指教。谢谢。

解析的很深刻，学习

深度剖析啊。。。 学习