On Thu, Jun 13, 2002 at 04:54:20PM -0700, Tim Bray wrote: > Ryan Bloom wrote: > >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.
Global means that you are guaranteed to have a mutex that can protect you across threads and processes at the same time. A process lock does not guarantee that threads in the same process will not enter the critical at the same time. A thread lock only works within one process. Therefore a global mutex was created to unify these two concepts. (On many platforms, as Ryan pointed out, a process mutex encompasses both concepts, but on some it doesn't, therefore we make a distinction.) > 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 proper way to think about this is in terms of the resource you are trying to protect. If you have a resource that is only shared between threads (ignore the MPM for now), then you only need an apr_thread_mutex. If you plan on having a resource stored in shared memory and used by threads in multiple processes then you'll have to go with an apr_global_mutex. If you plan for a shared-memory resource and use a global_mutex, but end up having your module being run under the prefork MPM, then you really don't have to worry about the overhead from the contention of the extra thread-mutex hidden in this global_mutex. In all cases that I've seen the overhead is negligible. > >>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? I agree with Ryan here, this warning should be changed to be less stern. > >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 It's not entirely that simple, since you really need to get some sort of cross-process scheduling mechanism. You also will have to deal with fair queuing issues, such as a slow stream of writers keeping readers from doing their work. IMHO the reason this isn't implemented in a cross-process context is because there is no good support at the OS level in all of the platforms that we wish to support in APR. -aaron
