From dev-return-43983-apmail-httpd-dev-archive=httpd.apache.org@httpd.apache.org Fri Sep 10 11:04:36 2004
Return-Path:
Delivered-To: apmail-httpd-dev-archive@www.apache.org
Received: (qmail 75574 invoked from network); 10 Sep 2004 11:04:34 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
by minotaur-2.apache.org with SMTP; 10 Sep 2004 11:04:34 -0000
Received: (qmail 90359 invoked by uid 500); 10 Sep 2004 11:04:26 -0000
Delivered-To: apmail-httpd-dev-archive@httpd.apache.org
Received: (qmail 90263 invoked by uid 500); 10 Sep 2004 11:04:25 -0000
Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
list-help:
list-unsubscribe:
list-post:
Delivered-To: mailing list dev@httpd.apache.org
Received: (qmail 90249 invoked by uid 99); 10 Sep 2004 11:04:24 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
tests=RCVD_BY_IP,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (hermes.apache.org: domain of trawick@gmail.com designates 64.233.170.196 as permitted sender)
Received: from [64.233.170.196] (HELO mproxy.gmail.com) (64.233.170.196)
by apache.org (qpsmtpd/0.28) with ESMTP; Fri, 10 Sep 2004 04:04:23 -0700
Received: by mproxy.gmail.com with SMTP id v30so397329rnb
for ; Fri, 10 Sep 2004 04:04:21 -0700 (PDT)
Received: by 10.38.8.74 with SMTP id 74mr1877697rnh;
Fri, 10 Sep 2004 04:04:21 -0700 (PDT)
Received: by 10.38.206.20 with HTTP; Fri, 10 Sep 2004 04:04:21 -0700 (PDT)
Message-ID:
Date: Fri, 10 Sep 2004 07:04:21 -0400
From: Jeff Trawick
Reply-To: Jeff Trawick
To: dev@httpd.apache.org
Subject: Re: Seg fault: Possible race conditions in mod_mem_cache.c
In-Reply-To:
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References:
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N
>Looking more closely at the implication of the submitted patch,
>I don't think we want to lock decrement_refcount() with a
>global mutex affecting the whole cache. Yes, it fixes the double free,
I think you should commit your last patch ASAP, and then somebody can
work out a redesign of the object management, one working design can
be replaced with another.
For a more granular mutex, there could be an array of mutexes with one
chosen based on the hash value? Use that mutex in place of a global
mutex.
>I am trying to find a solution using the current atomic APIs,
>but have not been succesfull so far. If someone has a better
>idea, I am more than open to try it.
I believe that the solution has to involve mutexes, as cache_cache.c
doesn't (can't?) increment a mutex as soon as a thread gets a handle
to an object.
A solution using more advanced atomic APIs (e.g.,
compare-double-and-swap) could be useful if the cache itself were
substantially redesigned, right? Do stuff like eliminate findability
of entries without actually freeing the entry, adding it to a queue of
pending operations, then the last searcher leaving the table has to
simultaneously set the searcher refcount to zero and dequeue the
pending operations, then process those pending operations.
--/--
Unfortunate that the current design requires a mutex to be held during
increment/decrement yet we use atomic operations on the refcount.
Those atomic operations result in lock/modify/unlock for many of us
(using the portable atomics).