refer:http://www.ixora.com.au/q+a/0009/23120936.htm
The _latch_wait_posting parameter has three possible values. The default value is 1, which means that latch wait posting is used for the "long" latches only. The alternative values are 0 (to disable latch wait posting entirely) and 2 (to enable latch wait posting for all latches).
The note that you have quoted is incorrect at 2 points: It implies that processes do not bother to spin for long latches. In fact they do. A cursory glance at some latching statistics should be enough to convince you of that fact. The note also states that all waiters are posted when a long latch is freed. Again, the statistics demonstrate that this is not the case, although you would need heavy contention to see it. If it were so, the waiters woken statistics would rise exponentially with sleeps during episodes of latch contention, whereas in fact it just rises linearly.
I'm reading your excellent "Oracle8i Internal Services" book. I've some questions about "latch wait posting" on page 27:
How does the Oracle process (releasing a latch) decide which process will be woken-up in latch free list?
How is that list managed? If it is FIFO, what is the diffrence from basic enqueue?
Is there still spinning for that mode, or is there just waiting for being posted by another process?
Note 104426.1 says:
Short Wait Latches
------------------
Short wait latches are characterised by the expectation that waiters will
not have to wait for any excessive duration prior to getting the latch.
Because of this, waiters spin on the cpu until the latch is freed.
Once the latch is freed the process grabs the latch and performs whatever
operation it was waiting to perform. When a short wait latch is freed by a
process no other processes are notified; the latch is simply freed.
Long Wait Latches
-----------------
Long wait latches are expected to be held for longer periods of time, so when
an attempt to get the latch is unsuccessful, the process goes to sleep for a
period of time, wakes up, and retries the latch get operation, repeating this
cycle until the latch get is successfully grabbed.
This procedure prevents excessive cpu being used as would be the case if the
procedure was to spin on a latch that is being held for a long time.
When the latch is freed, all waiters are posted to tell them that the latch
is free. Among other things this:
o prevents waiters from sleeping unnecessarily if the latch is free
o give waiters an equal chance of grabbing the latch
An example of a long wait latch is the library cache latch since
finding matching SQL in a hash chain has the potential to be a long running
activity.
The parameter _latch_wait_posting changes behavior. of short
wait and long wait latches.
I'm confused. If "Long Wait Latches" use the "latch wait posting" mecahnism, how does '_latch_wait_posting' change the behavior. of long wait latches?
