Bug#38941: fast mutexes in MySQL 5.1 have mutex contention when calling random()

The problem is that MySQL's 'fast' mutex implementation uses the
random() routine to determine the spin delay. Unfortunately, the
routine interface is not thead-safe and some implementations (eg:
glibc) might use a internal lock to protect the RNG state, causing
excessive locking contention if lots of threads are spinning on
a MySQL's 'fast' mutex. The code was also misusing the value
of the RAND_MAX macro, this macro represents the largest value
that can be returned from the rand() function, not random().

The solution is to use the quite simple Park-Miller random number
generator. The initial seed is set to 1 because the previously used
generator wasn't being seeded -- the initial seed is 1 if srandom()
is not called.

Futhermore, the 'fast' mutex implementation has several shortcomings
and provides no measurable performance benefit. Therefore, its use is
not recommended unless it provides directly measurable results.


include/my_pthread.h:
  Add field to keep the RNG state.
mysys/thr_mutex.c:
  Use a palliative per-mutex rng state to determine the spin delay.
  The RNG is not thread-safe but jumping a few sequences in the RNG
  is harmless.

1 files changed, 1 insertions, 0 deletions

diff --git a/include/my_pthread.h b/include/my_pthread.h
index 19cfb74c80f..e56614357e0 100644
--- a/include/my_pthread.h
+++ b/include/my_pthread.h
@@ -519,6 +519,7 @@ typedef struct st_my_pthread_fastmutex_t
 {
   pthread_mutex_t mutex;
   uint spins;
+  uint rng_state;
 } my_pthread_fastmutex_t;
 void fastmutex_global_init(void);