Bug #82328 Waiting in end_thr_alarm can be avoided for performance improvement
Submitted: 24 Jul 2016 22:35 Modified: 26 Jul 2016 14:06
Reporter: Mejbah Alam Email Updates:
Status: Not a Bug Impact on me:
Category:MySQL Server: Locking Severity:S5 (Performance)
Version:5.6.27 OS:Linux
Assigned to: CPU Architecture:Any
Tags: cond_timedwait, lock, thr_alarm

[24 Jul 2016 22:35] Mejbah Alam
In end_thr_alarm function of mysys/thr_alarm.c there is a optional free_structure feature for which to take effect program waits upto 10 seconds for alarm thread to die. For this, the function enters in a while loop and a cond_timedwait is used. But even after timeout and returning error from cond_timedwait it does nothing and deletes the queue entry anyway. The waiting loop is inside a critical section. 

Following is the part of code from mysys/thr_alarm.c

void end_thr_alarm(my_bool free_structures)
  if (alarm_aborted != 1)     /* If memory not freed */
 if (free_structures)
      struct timespec abstime;


      /* Wait until alarm thread dies */
      set_timespec(abstime, 10);    /* Wait up to 10 seconds */
      while (alarm_thread_running)
        int error= mysql_cond_timedwait(&COND_alarm, &LOCK_alarm, &abstime);
  if (error == ETIME || error == ETIMEDOUT)
    break;        /* Don't wait forever */
      alarm_aborted= 1;

How to repeat:
tested using sys bench :  
20000 create table, insert and drop table operations with 32 threads.

Suggested fix:
remove the waiting loop from end_thr_alarm function
[26 Jul 2016 14:06] MySQL Verification Team
Unfortunately, that delay is necessary because several other transactions might be using thread alarms.
[26 Jul 2016 14:17] MySQL Verification Team
Anyway, a code in MySQL server 5.7 has been so re-factored and extensively re-designed, so  that this function does not exist any more. And we do not intend to make drastic internal design changes to the old GA versions.