Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: modules-dev@httpd.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
References: <8ABEBF91-E02E-4608-A902-07855FC99A58@inmon.com>
In-Reply-To: <8ABEBF91-E02E-4608-A902-07855FC99A58@inmon.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: <705E31D4-D39A-4E0D-8785-B133B3FDA7B0@apache.org>
Content-Transfer-Encoding: quoted-printable
From: Nick Kew <niq@apache.org>
Subject: Re: per-worker-thread counter question
Date: Tue, 28 Jun 2011 10:10:21 +0100
To: modules-dev@httpd.apache.org


On 28 Jun 2011, at 03:57, Neil McKee wrote:

> Hi,
>=20
> Here's an easy question for someone who knows their way around...

Yeah, right :P=20

> I want to maintain a new global counter,  but for performance reasons =
I am reluctant to use a mutex or atomic_increment to update it.  I would =
rather maintain a separate counter for every worker-thread,  and only =
accumulate the global counter when required.  (If the per-worker-thread =
counter is 32-bit then I shouldn't even need a mutex when accumulating =
the total across all the current threads).

Have you tried apr_atomic and found an unacceptable performance impact,
or are you just assuming it?  I haven't tried it, but my gut feeling =
wouldn't
expect the overhead to be out of proportion.

> Obviously I shouldn't just declare something as "__thread apr_int32_t =
mycounter;" and mince it together as a linux-only hack.  I'd like to =
find the portable apr-library way to do it.   So I think I need to find =
the following:
>=20
> * - a hook that is called whenever a worker thread is started
> * - a hook that is called whenever a worker thread is about to die
> * - a hook to find_or_create a 32-bit integer that is private to the =
current worker-thread
> * - a fn to iterate (safely) over all the current worker threads

Absent something in the API, you're stuck.  Just to make it work across
standard MPMs will require care, and is unlikely to be future-proof.

> It's the last one that seems particularly elusive.  I could't find an =
ap_ or apr_ library call that seemed to do anything like that.

So your module would need to maintain its own register to iterate over.
Hats off if you can hack that with less overhead than apr_atomic or ...

> If this has all been done before,   please can you point me to the =
relevant module sources?  I think it would save me a lot of time.   =
Alternatively,  if you think I should just relax and use an atomic =
increment instead,  then let me know.

What springs to mind (as being supported in the API) is the scoreboard.
mod_slotmem (new in trunk) may be worth a look.

--=20
Nick Kew

Available for work, contract or permanent
http://www.webthing.com/~nick/cv.html