apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@ebuilt.com>
Subject Re: apr_lock.h lock scope question
Date Fri, 22 Jun 2001 14:37:11 GMT

> If you use APR_INTRAPROCESS, you will get a light-weight thread locking
> mechanism.  What more are you looking for.  In reality, for thread
> locking, we always end up using pthreads mutex's on Unix.

If by lightweight you mean (in apr_lock_acquire() for example):

function overhead from apr_lock_acquire()
a switch statement
two nested ifs
function overhead from apr_unix_lock_{inter,intra}()
another if
two returns


Then perhaps we have different definitions of "lightweight". Locks are
by definition used in conjunction with shared resources. Rapidly accessed
shared resources tend to be sources of lock contention. Any amount of
optimization we can do to "lighten" the call to acquire/release simple
mutexes can dramatically relieve this contention.

I am not asking for a major change. The apr_lock_*() routines are doing
a bunch of favors for us that I would happily trade for a whole bunch
of [aptly-named] functions.

> > - global resource syncronization (Will modules perhaps need true cross-
> >   process syncronization, or will the the process-group-only locking that
> >   we have now suffice? I suspect module authors will want true cross-process
> >   sync as they look for more creative ways to connect their [legacy] apps
> >   to apache).
> >    -- the weight of these calls will depend partially on platform support.
> 
> This is provided using APR_CROSSPROCESS
> 
> > - mutexes -- ideally this is just POSIX. Regardless, this is very lightweight.
> >   (much more lightweight and well defined than the current one-size-fits-all
> >    apr_lock_*() stuff :)
> 
> This is what we do.
> 
> > - conditionals and rwlocks (these pretty much go together, and would be
> >   built upon the mutex routines) -- much more heavy than simple mutexes,
> >   but IMHO widely useful throughout httpd and the modules.
> 
> Conditionals weren't portable when I looked at them.  Basically, Windows
> couldn't do them, but I'm not a windows programmer, and I didn't look at
> it too hard.

I'll admit that in terms of immediate itch-scratching, conditionals
are a bit of a stretch, but I do see an immediate need for rwlocks.

-aaron


Mime
View raw message