Mutex (test), mutex

Mutex (test), mutex
How to Use Mutex for cursor sharing

Kks uses mutex to protect a series of operations based on parent cursor parent and child cursor

For the parent cursor operation of the parent cursor:

• Different wait events are generated based on different operations:
  • Create a new cursor under a parent cursor ==> cursor: mutex X
  • Check a parent cursor ==> cursor: mutex S
  • Bind Value capture ==> cursor: mutex X
• Protects the mutex of the parent cursor from being embedded in the parent cursor structure.
• The Mutex type for the parent cursor Parent Cursor is 'cursor parent' (kgx_kks2 ).
• The Mutex wait events for the parent cursor parent Cursor are in the form of 'cursor: mutex * '.

How does Mutex Replace the library cache pin to protect the cursor heap?

• The traditional 'library cache pin' is replaced by default after 10.2.0.2, where the pin is replaced by Mutex and its ref count. A pin or hard parse sub-cursor heap is required when a process executes a cursor statement.
• In version 10.2.0.1, the function of replacing the PIN with some mutex code is not activated by default. In fact, it depends on the hidden parameter _ KKS_USE_MUTEX_PIN. After 10.2.0.2, the default value of _ KKS_USE_MUTEX_PIN is TRUE. In other words, in Version 10.2, we can still disable KKS to use MUTEX instead of PIN to protect CURSOR, but in version 11g, MUTEX is almost impossible to be disabled. Note that in 10.2, the library cache pin is no longer used as the cursor pin only when KKS actually uses MUTEX.
• Operations Based on Different cursor statistics have different wait events:
  • PIN a Cursor ==> Cursor: Pin S Wait on X for executing an SQL statement
  • When executing a Cursor and PIN Cursor, the cursor is being detected by other processes in S mode ==> Cursor: pin S
• When you try to recreate a Cursor ==> Cursor: pin X, this wait event is generally invisible because when a Cursor is being executed and needs to be rebuilt, another Cursor is created.
• Protects the mutex of the cursor from being embedded in the cursor structure.
• Mutex is of the 'cursor pin' type (kgx_kks3)
• Wait events are in the form of 'cursor: pin *'

Benefits of parsing and executing SQL statements when KKS uses MUTEX

In Version 10.2, the following are the main benefits of parsing and executing SQL statements from MUTEX:

• Create a new child cursor under a parent cursor
  • First, it is cheaper to construct a new sub-game. At that time, Maclean still had to warn you that too many sub-cursors under a parent cursor are not a good thing.
• Parent cursor Detection
  • The parent cursor needs to be properly checked before an appropriate cursor is found and executed. Mutex is also used to protect the detection of the parent cursor. Therefore, this detection is more cost-effective.
• Repeated execution of SQL statements already loaded in the Library Cache
  • In general, a process always needs to pin it before executing an SQL cursor.
  • If MUTEX is not used: If the cursor is in the OPEN state for future repeated execution, and the parameter cursor_space_for_time (this parameter is not recommended for CSFT currently) is TRUE, the library cache pin is not required for each repeated execution. If the cursor is in the OPEN state but cursor_space_for_time = false, the process always takes the library cache pin before executing the SQL cursor repeatedly.
  • Use MUTEX: conversely, if mutex is used to replace the library cache pin, you do not need to care about cursor_space_for_time. Only the first process requires a PIN. All subsequent processes simply need to obtain a shared reference on the mutex corresponding to the protection of the cursor heap.

Truly understand Mutex-related waits

The Mutex data structure contains the Holder id Holder ID, Ref Count, and other Mutex-related statistics. The Holder id corresponds to the session id (v $ session. sid) that holds the Mutex ).Special note, Ref Count isFor concurrent processes, refer to the number of Mutex processes in S mode..

When a Mutex is held in X mode, the Holder id is the session id of the mutex, And the Ref Count is 0.

Each shared S mode owner only adds Ref Count on mutex. A Mutex can be used for reference by a large number of session concurrency in S mode. However, note that the ref count update operation is serialized to avoid errors and maintain correct ref count in mutex.

Next we will introduce in detail the mutex share pin process during the execution of a cursor:

• A process requests a Mutex in SHRD mode and tries to temporarily modify the Mutex Holder ID
• If the Mutex is being updated by another user, the session sets the Holder id as the sid of the session. Then, the process adds ref count and the Holder id on the mutex. To put it simply, this Holder id truly implements the parallel control function. If the Holder id is set, the Mutex is either held in EXCL mode, or another process is applying for the Mutex in S mode (for example, updating Ref Count ). When updating Ref Count, the purpose of temporarily setting the holder id is to prevent other processes from updating the Mutex concurrently. These examples show that Mutex can be used as both Latch concurrency control and pin.
• If the Holder id has been set, the application process may enter the waiting event. For example, if the Mutex owner process is updating the Mutex in X mode, the applicant's wait event should be "cursor: pin S on X ". If the Holder does not "really want to hold" the Mutex, but only attempts to update its Ref Count, the second process will wait for the 'cursor: pin s' wait event; the operation that is actually updating the Ref count is very fast. It is a slight operation. When the first process is updating mutex, the subsequent application process will enter the spin loop for 255 times and wait until the previous process ends. When no Holder id exists on mutex (for example, if the former process has updated Ref Count), the applicant process sets the Holder ID as its SID and updates Ref Count, and clear the Holder id. If the mutex is not released after the first cycle of SPIN, the process waits and does not run on the CPU.

Mutex statistics View

V $ MUTEX_SLEEP

Shows the wait time, and the number of sleeps for each combination of mutex type and location.

Column	Datatype	Description
MUTEX_TYPE	VARCHAR2(32)	Type of action/object the mutex protects
LOCATION	VARCHAR2(40)	The code location where the waiter slept for the mutex
SLEEPS	NUMBER	Number of sleeps for thisMUTEX_TYPEAndLOCATION
WAIT_TIME	NUMBER	Wait time in microseconds

V$MUTEX_SLEEP_HISTORY

Displays time-series data. each row in this view is for a specific time, mutex type, location, requesting session and blocking session combination. that is, it shows data related to a specific session (requesting session) that slept while requesting a specific mutex type and location, because it was being held by a specific blocking session. the data in this view is contained within a circular buffer, with the most recent sleeps shown.

Column	Datatype	Description
SLEEP_TIMESTAMP	TIMESTAMP(6)	The last date/time thisMUTEX_TYPEAndLOCATIONWas slept for byREQUESTING_SESSION, While being held byBLOCKING_SESSION.
MUTEX_TYPE	VARCHAR2(32)	Type of action/object the mutex protects
GETS	NUMBER	The number of times the mutex/location was requested by the requesting session while being held by the blocking session.GETSIs only incremented once per request, irrespective of the number of sleeps required to obtain the mutex.
SLEEPS	NUMBER	The number of times the requestor had to sleep before obtaining the mutex
REQUESTING_SESSION	NUMBER	The SID of a session requesting the mutex
BLOCKING_SESSION	NUMBER	The SID of a session holding the mutex
LOCATION	VARCHAR2(40)	The code location where the waiter slept for the mutex
MUTEX_VALUE	RAW(4)	If the mutex is held in exclusive (X) mode, this column shows the SID of the blocking session, else it shows the number of sessions referencing the mutex in S mode.
P1	NUMBER	Internal use only
P1RAW	RAW(4)	Internal use only
P2	NUMBER	Internal use only
P3	NUMBER	Internal use only
P4	NUMBER	Internal use only
P5	VARCHAR2(64)	Internal use only.

Main sources of askmaclean!

How to Use Mutex

We do not recommend placing Mutex In the instance object or the constructor. If the instance object is recycled by GC, or the local variables created by the instance object are recycled by GC, the instance can run again.
Your code here is because Mutex is a local variable, so it will be recycled by GC from time to time after the construction is complete.
We recommend that you put the detection code in the Main method of Program. cs before Application. Run.

What does the C language if (mutex = 0) mean?

This function is definitely defined. You can compile it in VC and right-click the variable to find the declaration.
Mutex may be a mutex variable. I don't know how to use it. It is generally used to represent a window or variable and can only generate one
= 0 indicates that no instance has been generated.