httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@apache.org>
Subject Re: [PATCH] Use mutex locks in mod_specweb99.c
Date Thu, 12 Dec 2002 23:27:39 GMT
MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
>>-----Original Message-----
>>From: Greg Ames [mailto:gregames@apache.org]
> 
> [SNIP]
> 
> 
>>I dug into APR locks a little bit.  The apr_global_mutex_* 
>>functions turn into 
>>two separate syscalls, with #if APR_HAS_THREADS around the 
>>thread mutexing.  So 
>>unfortunately they wouldn't save us any syscalls :-( :-(  But 
>>they might save a 
>>little bit of function call overhead.
> 
> 
> Interesting.. I don't see it that way (atleast for HP-UX).. On HP-UX,
> replacing a file lock with global mutex lock definitely saves a lot of time
> (because of the absence of inode lookups, file-system locks etc.).. I'm
> expecting atleast a 5% increase..

you're using apr_global_mutex_lock/unlock/etc?  If so, cool!  From the 
apr_private.h you posted, it looks like that would replace the flock/fcntl with 
sysvsems on HP-UX.  I didn't know about the inode lookups etc., but that makes 
sense.  Sounds like this is the way we should go then.

> BTW, I had a doubt regarding the global_mutex_lock..
> as per my understanding :
> thread_mutex MEANS the mutex is local to the process

yep.

> proc_mutex MEANS the mutex is global to the system (shared mutex)

I think proc_mutex means that it locks between different processes, but not 
necessarily between threads in the same process.

> global_mutex_lock () is trying to lock the shared mutex (proc_mutex).

My understanding of apr_global_mutex_lock is that it combines the two properties 
above, i.e., locks cross-process and between threads in a process as well.

Greg




Mime
View raw message