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 Thu, 13 Jun 2002 23:34:49 GMT
> From: Tim Bray [mailto:tbray@textuality.com]
> So I'm poking through APR docs, and I find obvious candidates:  Global
> Locking Routines (apr_global_mutex_child_init etc), Process Locking
> Routines (apr_proc_mutex_create etc), Thread Mutex Routines
> (apr_thread_mutex_create etc), and Thread RWLock Routines
> (apr_thread_rwlock_create etc).
> Q0: Is there a better place to ask this kind of question or a TFM that
> can R?  I spent some time in

This is the right place.  Unfortunately, the docs aren't great
throughout APR, so people generally have to ask questions on this list.
If you want to doc what you learn, that would be fantastic.

> 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 just
use a process lock.

> 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 does
not automatically lock threads when using a process lock, then a thread
lock is also used.

> Q3: There is a stern warning in the global locking routines "There is
> considerable overhead in using this API if only cross-process or
> cross-thread mutual exclusion is required."  Suppose I want to build
> apache module that will run in both threaded and forking deployments;
> I shut up and swallow the overhead?  Or is this question evidence that
> I'm Unclear On The Concept?

The warning is too stern.  If you want to work in a process/thread
environment, you want to use a global lock.  The warning is there,
because many people default to global locks when a process or thread
lock will do.  For those people, the warning is appropriate.

> Q4: I really need more or less exactly the RWLock semantics.  Is there
> any particular reason this is thread-only?  With ref to Q3 above, does
> this suggest I'd better build the semantics based on the global locks?

The reason it doesn't currently exist, is that nobody has gotten around
to implementing it.  :-)  In reality, the thread RWLocks were easy, so
they were done quickly.  If you want to implement process RWLocks, then
we would welcome the contribution.


View raw message