>> About the mutex; We only take a mutex (at least in 5.1) if there is a
>> global read lock active, in which case it doesn't really matter if we
>> take one or two mutex. In normal operations there is no mutex, so
>> this is no argument for changing the behavior for FLUSH TABLES.
Konstantin> You're looking at lock.cc, where we have a dirty read of global
Konstantin> variable 'global_read_lock'. This is not the main use case
Konstantin> (thankfully), take a look at sql_insert.cc, sql_update.cc, where
Konstantin> we call wait_if_global_read_lock() explicitly.
I think it should be possible to even here do a dirty check for the
lock if we put our minds to it.
Konstantin> Besides, even if we forget the code in DML implementations and
Konstantin> trust the dirty read in lock.cc, there is still start_waiting*
Konstantin> function, which takes the mutex in all cases.
I assume that there is several solutions that we could use to get rid
of the mutex altogether. One way would to have a slot in 'thd' that
tells if the thread is 'active-writer' (and we can't start a global
read lock yet) and another slot that tells if the 'thd' has seen the
current global read lock. Both of these can be managed without any
locks and we would only need to take mutex in the case there is an
active global read lock in existence.