The MySQL SQL-layer (i.e. not InnoDB) has a custom spin-lock mutex implementation called "fast mutex". This mutex implementation is enabled by default on release builds (-DBUILD_CONFIG=mysql_release) for Linux. MySQL "fast" mutexes have a series of shortcomings and should be removed. 1) Spin-wait loops are hard to get right Due to the superscalar nature of modern processors, busy waiting can incur significant costs if not done properly as the processor generally needs to enforce certain constraints. But how to properly delay the loop tends to vary a lot between specific processors and is a burden that should be handled by the system provided implementation and not us. For example, Intel suggests the use of the PAUSE instruction as a hint for the processor and highlights that it's very important for hyperthreaded CPUs. There is also specific delay strategies on ppc, s390, ia64, etc. More details in subsection 2.1: http://www.intel.com/cd/ids/developer/asmo-na/eng/17689.htm The point is that system provided implementations knows better how to deal with this, which may eventually lead to better performance and power consumption. 2) Useless on single processor systems Busy waiting on single processor systems is completely useless as the thread will spin on the CPU until its time quantum expires. System implementations of spinlocks/mutexes usually know when the code is built for or is running on a uniprocessor system and will skip the busy waiting. 3) Fixed-point arithmetic The 'fast' mutex implementation relies on a PRNG to produce values for the spin delay. The formula for calculating the spin count includes a floating-point division operation that can be a bottleneck for multiprocessors systems that only have a single floating point unit (FPU) (ie: Sun SPARC Enterprise T5240). 4) Adaptive Mutex Nowadays most mainstream systems implement adaptive locks that provide a balance between busy waiting benefits and disadvantages by spinning on a lock only for a limited period and by not spinning at all if the lock is being held by a thread that is not currently running. Solaris mutexes are adaptive by default, Linux provides a attribute to make mutexes adaptive, etc. Another advantage of relying on system provided adaptive locks is that they usually offer environment variables or other means by which one can control the spin count, number of spinners, etc. 5) Starvation Constantly polling the mutex with pthread_mutex_trylock without eventually blocking until the mutex becomes available may lead to potential resource starvation if there is a high demand for the lock. Theoretically this may happen if the thread polling the mutex is the victim of unfavorable scheduling. 6) Offers no measurable advantage Various user reports and benchmarks have shown that there is no measurable performance advantage when MySQL is compiled with 'fast' mutex. 7) Naïveté Pretending that we can implement faster mutexes with such a simple code is just naive and labeling then as "fast mutex" without any evidence is misleading to our users. Associated bugs: BUG#38941: fast mutexes in MySQL 5.1 have mutex contention when calling random() BUG#37703: MySQL performance with and without Fast Mutexes using Sysbench Workload BUG#72805: mutex_delay() creating excess memory traffic, GCC mem barrier needed BUG#72806: mutex_delay() missing x86 pause instruction optimization BUG#72807: Set thread priority in my_pthread_fastmutex_lock User Documentation ================== http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-8.html
NF-1: Removing FAST_MUTEX support should have no negative performance implications.
I-1: The WL will remove the WITH_FAST_MUTEXES CMake build option. Since this option was enabled by default for release builds on Linux, it means that the release builds will change to now use default OS mutexes.