I studied the mutex stuff a bit when 10.2 came out, I'd say mutexes are less
intelligent than latches. But thanks to that, they are more lightweight and
thanks to quite large caches on modern CPUs we can afford having tons of
them - allowing very fine grained locking.
On my 32bit linux installation a mutex was 28 bytes in size, while a regular
latch structure was 110 bytes. In theory every library cache child should
have it's own mutex, but in practice I saw one case where two different
child objects were protected by the same mutex - that was what library cache
dump showed me anyway.
Mutex also acts as a pin structure, so there's no need to do another memory
write for pinning a cursor. Mutex allows immediate shared access to
resources it protects, the old approach would mean getting a library cache
latch in exclusive mode and then modifying the corresponding library cache
child pin structure.
Mutexes also don't maintain statistics on successful gets as latches do,
only sleeps are registered.
Thanks to all that, an immediately succeeding mutex get operation takes
several times less CPU instructions (and hits possibly less memory stalls),
from a 10gR2 perf tuning course I remember it was about 250 vs 50 CPU
instructions on IA32 platform.
Note that mutexes don't provide much benefit for poorly written
applications, for most benefit your apps should avoid any kind of
reparsing - keeping cursors open and cancelling them manually when interest
in query results has ended.
Tanel.
Thanks,
Yes, It is_kks_use_mutex_pin asking the (K)ompliation layer to use the mutex.I was on the road while replying that message hence the swap.
You are right on intelligent than latch part as latches themself become hot and introduce a false contention. Mutex on the other hand does not become hot as every structure can have (at least) theoritically its own mutex.And also mutex is lighter than latches.
-Gopal
On 4/28/06, Mladen Gogala <mgogala@xxxxxxxxx> wrote:Actually, it's "_kks_use_mutex_pin". The explanation that I have is that mutexes are "a bit more intelligent latches", which "are split in phases and can share locks in so called parse or compilation phases". The only Metalik paper that mentions the parameter is the note 216205.1.
--- K Gopalakrishnan <kaygopal@xxxxxxxxx> wrote:
> Charles: > > > Cursor: pin S wait on X is used like a replacement to library cache > pin either during compiling the child or the execution of the KGL > object. You see this wait when the mutex is held by the other session > on X mode. > > You can look the V$mutex_sleep views to find out the requesting > session and blocking session and deal this issue like the same old > library cache pin waits. > > If you want the traditional library cache mechanism to be used for > library cahce operations, you can turn this feature (!) off by setting > the parameter _use_kks_mutex_pin to false. > Other alternative is to look in the mutex_sleep view and find the > locations of the waits. This will give a clear picture on which > location it is waiting for that wait. > > -- > Best Regards, > K Gopalakrishnan > Co-Author: Oracle Wait Interface, Oracle Press 2004 > http://www.amazon.com/exec/obidos/tg/detail/-/007222729X/ > -- > //www.freelists.org/webpage/oracle-l > > > >
Mladen Gogala Oracle DBA
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
-- Best Regards, K Gopalakrishnan Co-Author: Oracle Wait Interface, Oracle Press 2004 http://www.amazon.com/exec/obidos/tg/detail/-/007222729X/ -- //www.freelists.org/webpage/oracle-l
-- //www.freelists.org/webpage/oracle-l
