aboutsummaryrefslogtreecommitdiff
path: root/pthreads/ptw32_rwlock_check_need_init.c
diff options
context:
space:
mode:
Diffstat (limited to 'pthreads/ptw32_rwlock_check_need_init.c')
-rw-r--r--pthreads/ptw32_rwlock_check_need_init.c22
1 files changed, 3 insertions, 19 deletions
diff --git a/pthreads/ptw32_rwlock_check_need_init.c b/pthreads/ptw32_rwlock_check_need_init.c
index ea2561eef..858ee271c 100644
--- a/pthreads/ptw32_rwlock_check_need_init.c
+++ b/pthreads/ptw32_rwlock_check_need_init.c
@@ -41,29 +41,13 @@ INLINE int
ptw32_rwlock_check_need_init (pthread_rwlock_t * rwlock)
{
int result = 0;
+ ptw32_mcs_local_node_t node;
/*
* The following guarded test is specifically for statically
* initialised rwlocks (via PTHREAD_RWLOCK_INITIALIZER).
- *
- * Note that by not providing this synchronisation we risk
- * introducing race conditions into applications which are
- * correctly written.
- *
- * Approach
- * --------
- * We know that static rwlocks 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_rwlock_test_init_lock);
+ ptw32_mcs_lock_acquire(&ptw32_rwlock_test_init_lock, &node);
/*
* We got here possibly under race
@@ -87,7 +71,7 @@ ptw32_rwlock_check_need_init (pthread_rwlock_t * rwlock)
result = EINVAL;
}
- LeaveCriticalSection (&ptw32_rwlock_test_init_lock);
+ ptw32_mcs_lock_release(&node);
return result;
}