Bug#17083851 BACKPORT BUG#11765744 TO 5.1, 5.5 AND 5.6

Description:
Original fix Bug#11765744 changed mutex to read write lock
to avoid multiple recursive lock acquire operation on 
LOCK_status mutex.  
On Windows, locking read-write lock recursively is not safe. 
Slim read-write locks, which MySQL uses if they are supported by
Windows version, do not support recursion according to their 
documentation. For our own implementation of read-write lock, 
which is used in cases when Windows version doesn't support SRW,
recursive locking of read-write lock can easily lead to deadlock
if there are concurrent lock requests.

Fix:  
This patch reverts the previous fix for bug#11765744 that used
read-write locks. Instead problem of recursive locking for
LOCK_status mutex is solved by tracking recursion level using 
counter in THD object and acquiring lock only once when we enter 
fill_status() function first time. 

1 files changed, 11 insertions, 0 deletions

diff --git a/sql/sql_class.h b/sql/sql_class.h
index 4543f9ef7a2..0942e9274b1 100644
--- a/sql/sql_class.h
+++ b/sql/sql_class.h
@@ -1443,6 +1443,17 @@ public:
 
   /* <> 0 if we are inside of trigger or stored function. */
   uint in_sub_stmt;
+
+  /** 
+    Used by fill_status() to avoid acquiring LOCK_status mutex twice
+    when this function is called recursively (e.g. queries 
+    that contains SELECT on I_S.GLOBAL_STATUS with subquery on the 
+    same I_S table).
+    Incremented each time fill_status() function is entered and 
+    decremented each time before it returns from the function.
+  */
+  uint fill_status_recursion_level;
+
   /* TRUE when the current top has SQL_LOG_BIN ON */
   bool sql_log_bin_toplevel;