I just finished reading chapter 7 which motivated me to revisit mutexes in chapter 4 (and to have a look at my previous questions / your answers relating to mutexes). In doing so, a new question regarding mutexes crossed my mind. On page 91 you write “Mutexes are small, and don’t have lists associated with them, we now have information pointing one way, the session knows which mutexes it is holding, but the mutex doesn’t know which sessions are holding it.”.
My question is, what happens when a session is holding mutexes and terminates unexpectedly (e.g. somebody killing the OS process with kill -9 on Unix)? There must be a way to notice that the mutex is being held by a no longer existing session, otherwise e.g. a library cache hash chain might remain unaccessible for all other sessions throughout the lifetime of the instance which I believe would not be acceptable.
So the question is where is the information stored that points from the session to the mutexes it holds? From my understanding of the Oracle memory achitecture, if it was in the PGA, it would not be accessible to other processes of the instance and therefore the information would be lost, once the session’s server process terminates. So I believe it must be in the SGA (or are there other, less known memory areas that are shared memory accessible to all processes of the instance)? Can you confirm (or rectify) this assumption and if it is in the SGA, do you know in which of the SGA components this information is stored?

Thank you
kind regards
Martin

First let me congratulate you on this wonderful book. As many have pointed out, it requires several round of readings to get the internal workings and mechanism clear. But, it is worth putting these efforts.

On the Exclusive and Shared Latch concept, as I understand, as the exclusive get is compatible with shared, the latch can be obtained in an exclusive mode. However, the work to be done in an exclusive mode will only be initiated once all the reader value is dropped to ZERO. In this case, while a process has obtained a latch or mutex (a session) in exclusive mode, it will wait until the count drops to ZERO. The session wating for the count drop however not wait for “Library Cache Mutex” wait. But, in the same scenario, if there is another session that requires the latch to be obtained in exclusive mode, since there is already a session that has set a write bit and is waiting for the reader count to drop zero, the new session has to wait on “Library Cache Mutex”. Also, the duration for this wait will become longer, if there are many readers holding the latch in shared mode. Am I correct ?

Regards
Vicky

I don’t think you’ve misunderstood any of the points. But I think there’s always the need to remember history. Some of the things that might look like unbalanced in terms of (say) CPU or memory utilisation may have seemed much more sensible 15 or 20 years ago; but the cost of change may override any consideration of change to a better strategy now.

Having said that, I have only come across a couple of occasions where the number of cache buffers chains latches really did need to be made much larger (factor of 2 or 4) than their default – so the current choice doesn’t seem to have too much of a negative impact

Just one more word regarding the size of the latch structure. I noticed that on page 66 you write there are between 100 and 200 bytes of infrastructure and instrumentation (in addition to the memory location used for the state and session information). If this really is the entire size of a latch, it would mean that a mutex would only use between 4 and 8 bytes of memory (assuming the factor 25 you mention)?
Also this would mean that the size of the latch structure is similar to the size of the buffer header (page 96). If this is the case, it seems very little to have only one latch per 32 hash buckets. With the number of hash buckets being twice the number of buffers, Oracle would therefore only allow 1/16 of the memory it uses for the buffer headers to be used for the latches protecting the hash chains – given the importance of concurrency I believe this is very little.

Do you agree with this considerations or did I misunderstand some point?

thank you
kind regards
Martin

The lock mode can anything from level 0 to level 6 (see http://jonathanlewis.wordpress.com/2010/06/21/locks/ ), and there are rules about when it is legal for different sessions to lock the same object in different modes.

For example, if you are locking a table in mode 3 (row-exclusive, probably updating a few rows) I cannot lock the same table in mode 6 (exclusive) until you have committed or rolled back. In the book example I would get to the head of the waiters queue, and have to wait for you (and any others updating the table) to get off the owners queue before I could join the owners queue.

at the bottom of page 79 you say:
“… only then can you attach yourself to the owners queue – provided the lock mode you want is compatible with the modes held by everyone currently on the owners queue”

Could you elaborate on what exactly “lock compatibility” means?

My brain produced a technical glitch there – for some reason I was thinking only of a mutex being held exclusive. Since only one process can hold exclusive there’s enough space in the mutex itself to identify the SID of the holder.

Thanks a lot for your answers and for the time you take to share your knowledge about Oracle. I have a follow-up question regarding your response (ii). What do you mean by “…a held mutex implicitly identifies the holder”? In the book you write (p. 91) “the session knows which mutexes it is holding, but the mutex doesn’t know which sessions are holding it”. Is that what you refer to when writing that the mutex implicitly identifies the holder?

thank you
kind regards
Martin

i) I think what you’re asking (rhetorically) and answering is the question: “why invent mutexes,, why not simply put a latch on every single item?”, and then arguing the case that the size of the memory structure would be the most significant reason for creating a new mechanism – and I agree; in fact I thought I’d made that point somewhere in the book, but perhaps I hadn’t. The thought behind the length of the code-path is that the bulk of the code exists to populate the parts of the latch structure that aren’t the “latch” itself. I’ll have to check what Tom says about the “7 times” – the size of the latch structure has varied dramatically over versions, and I’d have put the size difference closer to a factor of 25.

ii) I think a signiicant part of the code path is about instrumentation (and, in fact, somewhere in 10g or 11g, Oracle took out some of the code to count the number of sleep cycles a latch had been through); but there are also parts of the code that populate the structures with details of who is using the latch and from where in their code path. This secondary code can be removed for mutexes because a held mutex implicitly idenfies the holder, and the state object for the holder holds the information for why and where it is being held.

i) I think there are probably many questions of this type where the answer is, in part at least, simply “history”. Unless my memory is wrong, the enqueue stuff appeared in version 6, but the major coding effort for sharing cursors – hence the shared pool etc. – appeared in version 7. Given the difference in timing it’s easy to imagine a different group working on the various different problems with the sharedd pool and coming up with the generic strategy for allocating memory and simply applying it to the KGL pins and locks; there’s also the possibility that someone looked at the enqueue strategy and saw that it made the DBA responsible for defining the number of KGL pins and KGL locks (particularly) at database startup time and saw this as a difficult problem.

ii) I have no good ideas about this one. I could guess three possibilities (a) the question of scale is completely different, (b) don’t change code that isn’t causing a threat (c) you can’t do everything at once. In a similar vein, I have wondered if there are any plans to change the “cache buffers (LRU) chains” latches to mutexes