A session posts this event when requesting to pin a cursor in shared mode, cannot accomplish the pin by spinning, and therefore sleeps. Multiple sessions can pin the same cursor in shared mode, but only one session can hold a mutex in exclusive mode. Pinning increments the mutex's reference count, which is a serial operation. Because a session must pin a cursor to execute it (you don't want the cursor to be deallocated in the middle of execution), performance analysts have seen this event in production systems when a very popular cursor is repeatedly executed by many sessions.

A session posts this event when requesting to pin a cursor in exclusive mode, cannot accomplish the pin by spinning, and therefore sleeps. It takes only a single session with a shared mutex pin to prevent an exclusive acquisition. A cursor must be exclusively pinned while it is being created. You wouldn't want another session to create or change the same cursor at the same moment.

A session posts this event when requesting a pin in shared mode, but must wait because another session has the mutex in exclusive mode. For example, if a session simply wants to execute the cursor, it must acquire the mutex in shared mode. However, if another session is building or altering the cursor (which requires an exclusive pin) while the session is waiting to execute it, it will post this event. Performance analysts have seen this event when cursors are being rebuilt (perhaps an underlying table has been altered) while a number of sessions want to execute the cursor.