-----Original Message----- From: Greg Ames [mailto:[EMAIL PROTECTED]
[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
