httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bri...@apache.org
Subject cvs commit: httpd-2.0/server/mpm/worker fdqueue.c
Date Mon, 29 Sep 2003 03:58:41 GMT
brianp      2003/09/28 20:58:41

  Modified:    server/mpm/worker fdqueue.c
  Log:
  Switch to the new 32-bit APR atomic API for better portability
  (the old code assumed that apr_atomic_t and apr_uint32_t were interchangeable).
  Also, add more detailed comments on how one of the synchronization
  functions works.
  
  Revision  Changes    Path
  1.29      +18 -14    httpd-2.0/server/mpm/worker/fdqueue.c
  
  Index: fdqueue.c
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/server/mpm/worker/fdqueue.c,v
  retrieving revision 1.28
  retrieving revision 1.29
  diff -u -r1.28 -r1.29
  --- fdqueue.c	13 Sep 2003 03:45:50 -0000	1.28
  +++ fdqueue.c	29 Sep 2003 03:58:41 -0000	1.29
  @@ -149,8 +149,8 @@
       /* Atomically increment the count of idle workers */
       for (;;) {
           prev_idlers = queue_info->idlers;
  -        if (apr_atomic_cas(&(queue_info->idlers), prev_idlers + 1, prev_idlers)
  -            == prev_idlers) {
  +        if (apr_atomic_cas32(&(queue_info->idlers), prev_idlers + 1,
  +                             prev_idlers) == prev_idlers) {
               break;
           }
       }
  @@ -189,11 +189,21 @@
           if (rv != APR_SUCCESS) {
               return rv;
           }
  -        /* Re-check the idle worker count: one of the workers might
  -         * have incremented the count since we last checked it a
  -         * few lines above.  If it's still zero now that we're in
  -         * the mutex-protected region, it's safe to block on the
  -         * condition variable.
  +        /* Re-check the idle worker count to guard against a
  +         * race condition.  Now that we're in the mutex-protected
  +         * region, one of two things may have happened:
  +         *   - If the idle worker count is still zero, the
  +         *     workers are all still busy, so it's safe to
  +         *     block on a condition variable.
  +         *   - If the idle worker count is nonzero, then a
  +         *     worker has become idle since the first check
  +         *     of queue_info->idlers above.  It's possible
  +         *     that the worker has also signaled the condition
  +         *     variable--and if so, the listener missed it
  +         *     because it wasn't yet blocked on the condition
  +         *     variable.  But if the idle worker count is
  +         *     now nonzero, it's safe for this function to
  +         *     return immediately.
            */
           if (queue_info->idlers == 0) {
               rv = apr_thread_cond_wait(queue_info->wait_for_idler,
  @@ -214,13 +224,7 @@
       }
   
       /* Atomically decrement the idle worker count */
  -    for (;;) {
  -        apr_uint32_t prev_idlers = queue_info->idlers;
  -        if (apr_atomic_cas(&(queue_info->idlers), prev_idlers - 1, prev_idlers)
  -            == prev_idlers) {
  -            break;
  -        }
  -    }
  +    apr_atomic_dec32(&(queue_info->idlers));
   
       /* Atomically pop a pool from the recycled list */
       for (;;) {
  
  
  

Mime
View raw message