apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Havard" <bri...@kheldar.apana.org.au>
Subject Re: cvs commit: apr STATUS
Date Sun, 10 Feb 2002 14:44:17 GMT
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!                   |
 |  brianh@kheldar.apana.org.au  |  He's a very naughty boy!" - Life of Brian |
 ------------------------------------------------------------------------------


Mime
View raw message