> From: Tim Bray [mailto:[EMAIL PROTECTED] > > 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 just > > 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 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. 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 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? Yes. Ryan
