apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: Question re design/usage of lock/mutex routines
Date Fri, 14 Jun 2002 00:25:18 GMT
> From: Tim Bray [mailto:tbray@textuality.com]
> Ryan Bloom wrote:
> >>Q1: I assume global locks dispatch to Process or Thread locks as
> >>appropriate, with equivalent semantics?
> >
> > Pretty much.  The biggest difference is that on many platforms, the
> > process locks are global in and of themselves.  In that case, we
> > use a process lock.
> I'm not 100% clear on the sense of "global" here.

A global lock simply means that all processes and threads are locked.

> >>Q2: How do the global routines decide which to call?
> >
> > There is no real decision to make.  The global locks always use a
> > process lock, if you configured APR with threads and the platform
> > not automatically lock threads when using a process lock, then a
> > lock is also used.
> 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
> for the global routines to detect which of process/thread is
> from the httpd config or some other environmental condition?  Or even
> explicit init()-time signal from the caller?  Seems klunky to have all
> these triples of routines (thread/proc/global) with identical

The type of lock you use depends on what you are trying to do, and what
kind of mutex protection you need.  It doesn't make any sense to use a
global lock if you just want to lock threads.  On the other hand, if you
want to lock all threads and all processes, then using a global lock is
the best possible answer.

> >>Q3: There is a stern warning in the global locking routines "There
> >>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,



View raw message