BUG#21051: RESET QUERY CACHE very slow when query_cache_type=0

There were two problems: RESET QUERY CACHE took a long time to complete
and other threads were blocked during this time.

The patch does three things:
  1 fixes a bug with improper use of test-lock-test_again technique.
      AKA Double-Checked Locking is applicable here only in few places.
  2 Somewhat improves performance of RESET QUERY CACHE.
      Do my_hash_reset() instead of deleting elements one by one.  Note
      however that the slowdown also happens when inserting into sorted
      list of free blocks, should be rewritten using balanced tree.
  3 Makes RESET QUERY CACHE non-blocking.
      The patch adjusts the locking protocol of the query cache in the
      following way: it introduces a flag flush_in_progress, which is
      set when Query_cache::flush_cache() is in progress.  This call
      sets the flag on enter, and then releases the lock.  Every other
      call is able to acquire the lock, but does nothing if
      flush_in_progress is set (as if the query cache is disabled).
      The only exception is the concurrent calls to
      Query_cache::flush_cache(), that are blocked until the flush is
      over.  When leaving Query_cache::flush_cache(), the lock is
      acquired and the flag is reset, and one thread waiting on
      Query_cache::flush_cache() (if any) is notified that it may
      proceed.

1 files changed, 6 insertions, 0 deletions

diff --git a/include/mysql_com.h b/include/mysql_com.h
index ec1c133799f..aed32064dfe 100644
--- a/include/mysql_com.h
+++ b/include/mysql_com.h
@@ -210,7 +210,13 @@ typedef struct st_net {
   char last_error[MYSQL_ERRMSG_SIZE], sqlstate[SQLSTATE_LENGTH+1];
   unsigned int last_errno;
   unsigned char error;
+
+  /*
+    'query_cache_query' should be accessed only via query cache
+    functions and methods to maintain proper locking.
+  */
   gptr query_cache_query;
+
   my_bool report_error; /* We should report error (we have unreported error) */
   my_bool return_errno;
 } NET;