On Tue, 5 Feb 2002 08:30:22 -0800, Aaron Bannert wrote: >On Wed, Feb 06, 2002 at 12:07:58AM +1000, Brian Havard wrote: >> On OS/2 the only native mechanism that has cross-process lock behaviour is >> file locking (which is yuck because then you have to have a lock file). In >> fact I suspect the only reason we have cross-process locks at all is that >> some platforms only have file locks so the API was created to fit these >> platforms' capabilities. >> >> Wouldn't it be more useful & portable for the cross-process lock type to >> have the "lock all" behaviour, considering that on non-threaded platforms >> it amounts to the same thing? I'd expect that any platform that has threads >> would also have process sharable mutexes, making a "lock all" API universal >> to all platforms, threaded or not. > >I still may add an apr_global_mutex_t type (OtherBill doesn't agree with >the name) that works the same as LOCKALL used to work. > >> Is it ever useful to have the cross-process behaviour in a threaded >> application? (not meant as a rhetorical question but I can't think of any >> cases off the top of my head). > >Not in a purly threaded application, but apache tends to be a hybrid. >It is necessary for supporting single-threaded multi-process MPMs. > >Think of prefork: since most cross-process lock types on unix do not >simultaneously support thread locking. fcntl() behaves like this, for >example. A LOCKALL mechanism that used fcntl() would also have to use >pthread locks to keep the threads synchronized, which unnecessarily >burdens the lock/unlock implementations. Since prefork only needs >cross-process locking, the current apr_proc_mutex mechanism is ideal. > >OTOH, something like perchild could benefit from an apr_global_lock_t, >since it has both threads and processes that need to share a listen_rec >and serialize over the accept(). The implementation could decide if it >needed nested proc_mutex and thread_mutex types, or if there was a type >that could do it all at once.
Ok, so the cross-process lock is essentially a performance optimization for when you're running single threaded processes on a multi-threading capable system that doesn't have an efficient global lock mechanism. If that's the case then implementing apr_proc_mutex using a global lock would be ok on platforms that DO have an efficient native mechanism with that behaviour. By using apr_proc_mutex you're saying "I don't require inter-thread locking but don't care if I get it". -- ______________________________________________________________________________ | Brian Havard | "He is not the messiah! | | [EMAIL PROTECTED] | He's a very naughty boy!" - Life of Brian | ------------------------------------------------------------------------------
