aboutsummaryrefslogtreecommitdiff
path: root/pthreads/ptw32_mutex_check_need_init.c
diff options
context:
space:
mode:
Diffstat (limited to 'pthreads/ptw32_mutex_check_need_init.c')
-rw-r--r--pthreads/ptw32_mutex_check_need_init.c26
1 files changed, 3 insertions, 23 deletions
diff --git a/pthreads/ptw32_mutex_check_need_init.c b/pthreads/ptw32_mutex_check_need_init.c
index 35ec366bd..897db3c68 100644
--- a/pthreads/ptw32_mutex_check_need_init.c
+++ b/pthreads/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);
}