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) Navet

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

You must be logged in to tag this worklog