Just like latches, mutexes are hooked into the wait interface while sleeping. Also, spinning on a mutex consumes CPU resources and will be recorded as such. To save resources (said another way, to optimize internal resources), mutex get requests are not recorded; only sleep activity is recorded. There are v$mutex_sleep (like v$latch), v$mutex_sleep_history, and dba_hist_mutex_sleep views.

Figures 3-18 and 3-19 are examples of what you could see with severe mutex contention. Wait events starting with cursor are related to acquiring a mutex to access a cursor in the library cache. It's unfortunate that the wait event name does not start with mutex, but understanding that mutexes are replacing library-related latches, it does make sense.

Resolving the most common mutex issues is detailed in their respective Oracle internals chapter. For now, you are fully prepared to detect if mutex contention exists, if it is significant, and specifically which mutex is being requested.