bzr push into mysql-5.1 branch (davi:2669 to 2670) Bug#38477

[Davi Arnaut]

 2670 Davi Arnaut	2008-10-15
      Bug#38477: my_pthread_setprio can change dispatch class on Solaris, not just priority
      
      The problem is that the function used by the server to increase
      the thread's priority (pthread_setschedparam) has the unintended
      side-effect of changing the calling thread scheduling policy,
      possibly overwriting a scheduling policy set by a sysadmin.
      
      The solution is to rely on the pthread_setschedprio function, if
      available, as it only changes the scheduling priority and does not
      change the scheduling policy. This function is usually available on
      Solaris and Linux, but it use won't work by default on Linux as the
      the default scheduling policy only accepts a static priority 0 -- this
      is acceptable for now as priority changing on Linux is broken anyway.
modified:
  configure.in
  include/my_pthread.h

 2669 Davi Arnaut	2008-10-15
      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.
modified:
  include/my_pthread.h
  mysys/thr_mutex.c

=== modified file 'configure.in'
--- a/configure.in	2008-10-10 11:54:46 +0000
+++ b/configure.in	2008-10-15 22:28:26 +0000
@@ -2040,7 +2040,7 @@ AC_CHECK_FUNCS(alarm bcmp bfill bmove bs
   mkstemp mlockall perror poll pread pthread_attr_create mmap mmap64 getpagesize \
   pthread_attr_getstacksize pthread_attr_setprio pthread_attr_setschedparam \
   pthread_attr_setstacksize pthread_condattr_create pthread_getsequence_np \
-  pthread_key_delete pthread_rwlock_rdlock pthread_setprio \
+  pthread_key_delete pthread_rwlock_rdlock pthread_setprio pthread_setschedprio \
   pthread_setprio_np pthread_setschedparam pthread_sigmask readlink \
   realpath rename rint rwlock_init setupterm \
   shmget shmat shmdt shmctl sigaction sigemptyset sigaddset \

=== modified file 'include/my_pthread.h'
--- a/include/my_pthread.h	2008-10-15 22:21:00 +0000
+++ b/include/my_pthread.h	2008-10-15 22:28:26 +0000
@@ -279,6 +279,8 @@ int sigwait(sigset_t *setp, int *sigp);	
 #define my_pthread_setprio(A,B) pthread_setprio_np((A),(B))
 #elif defined(HAVE_PTHREAD_SETPRIO)
 #define my_pthread_setprio(A,B) pthread_setprio((A),(B))
+#elif defined(HAVE_PTHREAD_SETSCHEDPRIO)
+#define my_pthread_setprio(A,B) pthread_setschedprio((A),(B))
 #else
 extern void my_pthread_setprio(pthread_t thread_id,int prior);
 #endif