This content has been marked as final. Show 12 replies
1) Simply put mutexes are memory structures. They are used to serialize the access to shared structures. IMHO their most important characteristics are two. First, they can be taken in shared or exclusive mode. Second, getting a mutex can be done in wait or no-wait mode.
2) The main advantages over latches are that mutexes requires less memory and are faster to get and release.
Thanks for the reply.
1) Yes I understand that they are exactly nothing but the low level locks on the memory structures to protect their integerity.Thats the same thing that is latches are meant for.
Ok the benefits that you have mentioned , out of that the shared and exclusive mode access looks the relevant one. The other one is same with the latches as they are also acquired in the same mode of immediate or willing to wait correct ?
2) Well the smaller is indeed there.The faster I amnot sure still why. What Orcle says , that as like latches which are available for either one or multiple structures as one resource manager , so their contention can also come.This can be leading to an assumption to a "false contention" sort of thing like suppose there are lots of sessions looking for statements in the shared pool than the library cache latch will come under contention. Now this is a false contention if we just look at it as if sessions are looking for soft parsed cursors than its a good thing but because the looking mechanism, latch is not available so its actualy is a contention which will be removed with the help of mutexes as they wil be allocated as per the the structure so there wont be a starvation issue like latches with them. I am sure besides this , there must be some thing more relevant for mutexes also there which I am trying to look.
Thanks a bunch for the input and reply.
acquired in the same mode of immediate or willing to wait correct ?Yes.
The faster I am not sure still why.The code path to get and release them is shorter.
This can be leading to an assumption to a "false contention" sort of thingThe reduced size helps avoiding false contention. In fact, when a latch protects several, independent, structures, false contention might happen. Since mutexes takes less memory, the database engine is able to allocate more of them and, therefore, reduced the likelihood of having false contention.
I am sure besides this , there must be some thing more relevant forTo me it seams that since mutexes can do the same things as latches do by using less memory and in a more performant way, there are already enough good reason for using them!
mutexes also there which I am trying to look.
Latch is considered a type of [generic definition of] Mutex.
However, in some recent docs, I have noticed that Oracle is starting to talk about mutex as a new lightweight mututla exclusion memory structure and code as a substitute for latch as described by Chris.
One reference is Note:433631.1
In Oracle, latches and mutexes are different things and managed using different modules. KSL* modules for latches and KGX* for mutexes.
As Chris said, general mutex operatins require less CPU instructions than latch operations (as they aren't as sophisticated as latches and don't maintain get/miss counts as latches do).
But the main scalability benefit comes from that there's a mutex structure in each child cursor handle and the mutex itself acts as cursor pin structure. So if you have a cursor open (or cached in session cursor cache) you don't need to get the library cache latch (which was previously needed for changing cursor pin status), but you can modify the cursor's mutex refcount directly (with help of pointers in open cursor state area in sessions UGA).
Therefore you have much higher scalability when pinning/unpinning cursors (no library cache latching needed, virtually no false contention) and no separate pin structures need to be allocated/maintained.
1) library cache latching is still needed for parsing etc, the mutexes address only the pinning issue in library cache
2) mutexes are currently used for library cache cursors (not other objects like PL/SQL stored procs, table defs etc)
3) As mutexes are a generic mechanism (not library cache specific) they're used in V$SQLSTATS underlying structures too
4) When mutexes are enabled, you won't see cursor pins from X$KGLPN anymore (as X$KGLPN is a fixed table based on the KGL pin array - which wouldn't be used for cursors anymore)
First thanks for the reply. yes I agree with the part that mutex are smaller and also they remove the "false contention" part which can be there with latches.
To me it seams that since mutexes can do the same things as latches do by using less memory and in a more performant way, there are already enough good reason for using them!
right:-).Tanel gave a good explanation of it. Also I got a good document about it just now.
Thanks for the explanation.
Yingkuan,Understand. I also failed to find good article to discuss this topic in detail. I assume Oracle thought this too technical to post to general public.
I dont have the official aricle with me to prove that
Oracle is doing mutex implementation. I tried to
search alot for this details but I wasnt able to
find relevant details so I asked, Believe me ( I know
its not good to say, proof is required) but its true
Nonetheless, Tanel seems give a good explanation .