From 6e3ac5c605d5062279178b3ea0b853d0e9cf7cc9 Mon Sep 17 00:00:00 2001
From: rpj <rpj>
Date: Thu, 10 Mar 2011 13:40:16 +0000
Subject: Replace global Critical Sections with MCS Queue locks

---
 ptw32_mutex_check_need_init.c | 26 +++-----------------------
 1 file changed, 3 insertions(+), 23 deletions(-)

(limited to 'ptw32_mutex_check_need_init.c')

diff --git a/ptw32_mutex_check_need_init.c b/ptw32_mutex_check_need_init.c
index 35ec366..897db3c 100644
--- a/ptw32_mutex_check_need_init.c
+++ b/ptw32_mutex_check_need_init.c
@@ -50,29 +50,9 @@ ptw32_mutex_check_need_init (pthread_mutex_t * mutex)
 {
   register int result = 0;
   register pthread_mutex_t mtx;
+  ptw32_mcs_local_node_t node;
 
-  /*
-   * The following guarded test is specifically for statically
-   * initialised mutexes (via PTHREAD_MUTEX_INITIALIZER).
-   *
-   * Note that by not providing this synchronisation we risk
-   * introducing race conditions into applications which are
-   * correctly written.
-   *
-   * Approach
-   * --------
-   * We know that static mutexes will not be PROCESS_SHARED
-   * so we can serialise access to internal state using
-   * Win32 Critical Sections rather than Win32 Mutexes.
-   *
-   * If using a single global lock slows applications down too much,
-   * multiple global locks could be created and hashed on some random
-   * value associated with each mutex, the pointer perhaps. At a guess,
-   * a good value for the optimal number of global locks might be
-   * the number of processors + 1.
-   *
-   */
-  EnterCriticalSection (&ptw32_mutex_test_init_lock);
+  ptw32_mcs_lock_acquire(&ptw32_mutex_test_init_lock, &node);
 
   /*
    * We got here possibly under race
@@ -106,7 +86,7 @@ ptw32_mutex_check_need_init (pthread_mutex_t * mutex)
       result = EINVAL;
     }
 
-  LeaveCriticalSection (&ptw32_mutex_test_init_lock);
+  ptw32_mcs_lock_release(&node);
 
   return (result);
 }
-- 
cgit v1.2.3