You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Aaron Bannert <aa...@clove.org> on 2002/02/04 20:17:38 UTC
Re: cvs commit: apr STATUS
Can someone please comment on the state of the OS/2 and Netware lock
implementation? Is it unnecessary or even senseless to implement
a cross-process lock on Netware (where I've been told there are
only threads)?
-aaron
On Mon, Feb 04, 2002 at 07:15:20PM -0000, aaron@apache.org wrote:
> aaron 02/02/04 11:15:20
>
> Modified: . STATUS
> Log:
> The major parts of the new lock API are complete, AFAICT. Move the less
> critical (or perhaps not implementable) pieces down to non-showstopper
> status.
>
> Left a note that we must not make a release of APR with both lock
> APIs, or we may have to support both lock APIs forever, which would
> be unfortunate.
>
> Also, it appears that Beos' apr_thread_cond now works, thanks to David.
>
> Revision Changes Path
> 1.97 +7 -6 apr/STATUS
>
> Index: STATUS
> ===================================================================
> RCS file: /home/cvs/apr/STATUS,v
> retrieving revision 1.96
> retrieving revision 1.97
> diff -u -r1.96 -r1.97
> --- STATUS 29 Jan 2002 16:10:14 -0000 1.96
> +++ STATUS 4 Feb 2002 19:15:20 -0000 1.97
> @@ -1,5 +1,5 @@
> APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS: -*-text-*-
> -Last modified at [$Date: 2002/01/29 16:10:14 $]
> +Last modified at [$Date: 2002/02/04 19:15:20 $]
>
> Release:
>
> @@ -32,12 +32,15 @@
> since apr_proc_create didn't allocate the apr_proc_t storage.
> (Aren't transparent types swell?) Suggestions?
>
> + * The new lock API is a full replacement for the old API. Before
> + we do a major APR release, we must deprecate the old locks API,
> + lest we support 2 lock APIs in perpetuity.
> +
> +RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
> +
> * The new lock API is a full replacement for the old API, but is
> not yet complete on all platforms. Components that are incomplete
> or missing include:
> - Beos: apr_thread_cond_*()
> - Initial code committed. Aaron has some concerns, David agrees
> - and will find time to address the issues.
> Netware: apr_proc_mutex_*() (Is proc_mutex unnecessary on Netware?)
> OS/2: apr_thread_cond_*(), apr_proc_mutex_*()
>
> @@ -47,8 +50,6 @@
> Unix: apr_thread_rwlock_*() for platforms w/o rwlocks in pthread
> Win32: apr_thread_rwlock_try*lock(), apr_thread_cond_timedwait(),
> apr_proc_mutex_*() (Is proc_mutex unnecessary on Win32?)
> -
> -RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
>
> * Need to contemplate apr_strftime... platforms vary. OtherBill
> suggested this solution (but has no time to implement):
>
>
>
Re: cvs commit: apr STATUS
Posted by Aaron Bannert <aa...@clove.org>.
On Mon, Feb 11, 2002 at 12:44:17AM +1000, Brian Havard wrote:
> 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".
Yes, that is it exactly. :)
-aaron
Re: cvs commit: apr STATUS
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
>From out in left field... this was sitting amidst my drafts. Dunno how
relevant it still is.
From: "Aaron Bannert" <aa...@clove.org>
Sent: Tuesday, February 05, 2002 10:30 AM
> 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.
Same on Win32 AFAICT... designers really never envisioned a need for cross-proc
only locks when most coders on win32 end up in thread deadlocks anyways :)
> > 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.
I will take that name, thank you :)
> > 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.
>
> 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.
Yup. And the Win32 and OS2 MPM will be much simpler with your new
apr_global_mutex_t lock, than using a crossproc [file] lock.
Bill
Re: cvs commit: apr STATUS
Posted by Brian Havard <br...@kheldar.apana.org.au>.
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 |
------------------------------------------------------------------------------
Re: cvs commit: apr STATUS
Posted by Aaron Bannert <aa...@clove.org>.
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.
-aaron
Re: cvs commit: apr STATUS
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Mon, 4 Feb 2002 11:17:38 -0800, Aaron Bannert wrote:
>Can someone please comment on the state of the OS/2 and Netware lock
>implementation? Is it unnecessary or even senseless to implement
>a cross-process lock on Netware (where I've been told there are
>only threads)?
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.
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).
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------