rbb 01/09/01 09:48:58
Modified: threadproc/win32 thread.c
Log:
One more iteration on apr_thread_once on Windows. Now we use
InterlockedExchange, and we don't have the wrapping problem, so
we can also remove the quick escape hatch.
Submitted by: Sander Striker <[EMAIL PROTECTED]>
Revision Changes Path
1.39 +1 -13 apr/threadproc/win32/thread.c
Index: thread.c
===================================================================
RCS file: /home/cvs/apr/threadproc/win32/thread.c,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -r1.38 -r1.39
--- thread.c 2001/09/01 07:29:07 1.38
+++ thread.c 2001/09/01 16:48:58 1.39
@@ -231,19 +231,7 @@
APR_DECLARE(apr_status_t) apr_thread_once(apr_thread_once_t *control,
void (*func)(void))
{
- /* Quick escape hatch, and bug fix. The InterlockedIncrement
- * call is just incrementing a long int, so it has the potential
- * to wrap. Very unlikely, but still, that would be an almost
- * impossible bug to hunt. With this, we might see one or two
- * calls to InterlockedIncrement, but never enough to wrap the
- * long int. This also saves us a kernel call for most calls to
- * this function.
- */
- if (control->value) {
- return APR_SUCCESS;
- }
- InterlockedIncrement(&control->value);
- if (control->value == 1) {
+ if (!InterlockedExchange(&control->value, 1)) {
func();
}
return APR_SUCCESS;
