@@ -170,10 +170,32 @@ typedef struct st_relay_log_info
170
170
/*
171
171
Handling of the relay_log_space_limit optional constraint.
172
172
ignore_log_space_limit is used to resolve a deadlock between I/O and SQL
173
- threads, it makes the I/O thread temporarily forget about the constraint
173
+ threads, the SQL thread sets it to unblock the I/O thread and make it
174
+ temporarily forget about the constraint. It is declared volatile because we
175
+ have this loop in the I/O thread (slave.cc):
176
+ while (rli->log_space_limit < rli->log_space_total &&
177
+ !(slave_killed=io_slave_killed(thd,mi)) &&
178
+ !rli->ignore_log_space_limit)
179
+ pthread_cond_wait(&rli->log_space_cond, &rli->log_space_lock);
180
+ According to Monty, on some systems pthread_cond_wait() could be inline,
181
+ and so the loop be optimized by the compiler, so rli->ignore_log_space_limit
182
+ could be considered constant and the loop never ends, even if the SQL thread
183
+ has set rli->ignore_log_space_limit to 1 (and called
184
+ pthread_cond_broadcast()) to break the loop in the I/O thread.
185
+ By declaring it volatile, we are sure that the variable will not be
186
+ considered constant and that the loop can be broken.
187
+ This is the same for all bool variables used by a thread to inform another
188
+ thread that something has changed: thd->killed, rli->abort_slave,
189
+ MYSQL_LOG::log_type; they are all volatile.
190
+ Quoting:
191
+ <serg> while (a>0) { wait_for_condition }
192
+ <serg> here a should be volatile ?
193
+ <monty> serg: in most system no, but on some yes
194
+ <serg> on what systems ?
195
+ <monty> On any system where pthread_mutex is a macro.
174
196
*/
175
197
ulonglong log_space_limit ,log_space_total ;
176
- bool ignore_log_space_limit ;
198
+ volatile bool ignore_log_space_limit ;
177
199
178
200
/*
179
201
InnoDB internally stores the master log position it has processed
0 commit comments