apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bray <tb...@textuality.com>
Subject Re: Question re design/usage of lock/mutex routines
Date Thu, 13 Jun 2002 23:54:20 GMT
Ryan Bloom wrote:

>>Q0: Is there a better place to ask this kind of question
> 
> This is the right place.  

Heh-heh.  That means you get follow-ups.

>>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.

I'm not 100% clear on the sense of "global" here.

>>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.

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.

>>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?

>>Q4: I really need more or less exactly the RWLock semantics.  Is there
>>any particular reason this is thread-only? 
> 
> 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


Mime
View raw message