| 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 | ||
[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.

Description: 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) { DBUG_ENTER("end_thr_alarm"); if (alarm_aborted != 1) /* If memory not freed */ { mysql_mutex_lock(&LOCK_alarm); .. .. .. if (free_structures) { struct timespec abstime; DBUG_ASSERT(!alarm_queue.elements); /* 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 */ } delete_queue(&alarm_queue); alarm_aborted= 1; mysql_mutex_unlock(&LOCK_alarm); ... ... 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