apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: Question re design/usage of lock/mutex routines
Date Fri, 14 Jun 2002 00:16:11 GMT
On Thu, Jun 13, 2002 at 04:54:20PM -0700, Tim Bray wrote:
> Ryan Bloom wrote:
> >Pretty much.  The biggest difference is that on many platforms, the
> >process locks are global in and of themselves.  In that case, we just
> >use a process lock.
> I'm not 100% clear on the sense of "global" here.

Global means that you are guaranteed to have a mutex that can protect
you across threads and processes at the same time. A process lock does
not guarantee that threads in the same process will not enter the
critical at the same time. A thread lock only works within one process.
Therefore a global mutex was created to unify these two concepts.
(On many platforms, as Ryan pointed out, a process mutex encompasses
both concepts, but on some it doesn't, therefore we make a distinction.)

> Which suggests that if you're running threaded, you *really* win by 
> using the apr_thread_mutex_* stuff?  Seems it be nice if there was a way 
> for the global routines to detect which of process/thread is appropriate 
> from the httpd config or some other environmental condition?  Or even on 
> explicit init()-time signal from the caller?  Seems klunky to have all 
> these triples of routines (thread/proc/global) with identical semantics.

The proper way to think about this is in terms of the resource you are
trying to protect. If you have a resource that is only shared between
threads (ignore the MPM for now), then you only need an apr_thread_mutex.
If you plan on having a resource stored in shared memory and used by
threads in multiple processes then you'll have to go with an

If you plan for a shared-memory resource and use a global_mutex,
but end up having your module being run under the prefork MPM, then
you really don't have to worry about the overhead from the contention
of the extra thread-mutex hidden in this global_mutex. In all cases
that I've seen the overhead is negligible.

> >>Q3: There is a stern warning in the global locking routines "There is
> >>considerable overhead in using this API
> >
> >The warning is too stern.  If you want to work in a process/thread
> >environment...
> Which I always do if I want to run in httpd in the general case, right?

I agree with Ryan here, this warning should be changed to be less stern.

> >The reason it doesn't currently exist, is that nobody has gotten around
> >to implementing it.  :-)  
> Good enough - if we do the module I'll do it; I agree it doesn't feel 
> like rocket science, particularly given the number of pieces that are 
> already there.   -Tim

It's not entirely that simple, since you really need to get some sort
of cross-process scheduling mechanism. You also will have to deal with
fair queuing issues, such as a slow stream of writers keeping readers
from doing their work. IMHO the reason this isn't implemented in
a cross-process context is because there is no good support at the OS
level in all of the platforms that we wish to support in APR.


View raw message