For every mutex instrumented in the code, the Performance Schema provides the following information. 

•The setup_instruments  table lists the name of the instrumentation point, with the prefix wait/ synch/mutex/ . 

•When some code creates a mutex, a row is added to the mutex_instances  table. The OBJECT_INSTANCE_BEGIN  column is a property that uniquely identifies the mutex. 

•When a thread attempts to lock a mutex, the events_waits_current  table shows a row for that thread, indicating that it is waiting on a mutex (in the EVENT_NAME  column), and indicating which mutex is waited on (in the OBJECT_INSTANCE_BEGIN  column). 

•When a thread succeeds in locking a mutex: 

• events_waits_current  shows that the wait on the mutex is completed (in the TIMER_END  and TIMER_WAIT  columns) 

•The completed wait event is added to the events_waits_history  and events_waits_history_long  tables 

• mutex_instances  shows that the mutex is now owned by the thread (in the THREAD_ID  column). 

•When a thread unlocks a mutex, mutex_instances  shows that the mutex now has no owner (the THREAD_ID  column is NULL ). 

•When a mutex object is destroyed, the corresponding row is removed from mutex_instances . 

By performing queries on both of the following tables, a monitoring application or a DBA can detect bottlenecks or deadlocks between threads that involve mutexes: 

## 27.12.3.4 The rwlock_instances Table 

• events_waits_current , to see what mutex a thread is waiting for 

• mutex_instances , to see which other thread currently owns a mutex 

The rwlock_instances  table lists all the rwlock (read write lock) instances seen by the Performance Schema while the server executes. An rwlock  is a synchronization mechanism used in the code to enforce that threads at a given time can have access to some common resource following certain rules. The resource is said to be “protected”  by the rwlock . The access is either shared (many threads can have a read lock at the same time), exclusive (only one thread can have a write lock at a given time), or shared- exclusive (a thread can have a write lock while permitting inconsistent reads by other threads). Shared- exclusive access is otherwise known as an sxlock  and optimizes concurrency and improves scalability for read-write workloads. 

Depending on how many threads are requesting a lock, and the nature of the locks requested, access can be either granted in shared mode, exclusive mode, shared-exclusive mode or not granted at all, waiting for other threads to finish first. 

The rwlock_instances  table has these columns: 

• NAME 

The instrument name associated with the lock. 

• OBJECT_INSTANCE_BEGIN 

The address in memory of the instrumented lock. 

