apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@ebuilt.com>
Subject Re: apr_lock.h lock scope question
Date Mon, 25 Jun 2001 16:35:44 GMT
I still completely fail to see any place where LOCKALL would need to be
different than CROSS_PROCESS.

Even in the case where APR_PROCESS_LOCK_IS_GLOBAL is _not_ #defined,
and the lock was created with type APR_LOCKALL, (if I'm reading this
correctly) acquire() will do:

apr_unix_lock_intra(lock)
apr_unix_lock_inter(lock)

and release() will do:

apr_unix_unlock_intra(lock)
apr_unix_unlock_inter(lock)


To me it seems that the intraprocess lock would merely serve as a
bottleneck (for better or worse) for local-process locks, while the
interprocess lock would be the only lock protecting the central resource.

This is compoundedly so when you consider our primary example, where two
multithreaded processes will compete for the acquire() lock. They can each
simultaneously acquire the intraprocess lock in their own memory-space,
but will sill have to compete for the interprocess lock.

* If we are to worry about multiple simultaneous calls to
apr_unix_lock_intra() from within the same process-space,
then perhaps the implementation of that function should depend on
APR_PROCESS_LOCK_IS_GLOBAL is defined.  We would then be able to separate
CROSS_PROCESS from INTRAPROCESS.

I also do not see LOCK_ALL used for lock implementation anywhere except
in the apr/locks/unix/lock.c code. (There is once case in the win32 code,
but it appears to treat LOCK_ALL and CROSS_PROCESS the same), so the
who thing seems to hinge on APR_PROCESS_LOCK_IS_GLOBAL. (I could be
wrong here :)

-aaron


On Mon, Jun 25, 2001 at 11:32:34AM -0400, Jeff Trawick wrote:
> Aaron Bannert <aaron@ebuilt.com> writes:
> 
> > > *There would have to be an intermediate routine for APR_LOCK_ALL on
> > > most platforms when APR is built with thread support.
> > 
> > I still disagree with apr_lock_*() providing both
> > INTRAPROCESS and CROSS_PROCESS  *in the same function calls*.
> 
> If you don't have them both in the same function calls then how do you
> implement APR_LOCK_ALL?  It is nice to have APR_LOCK_ALL 'cause that
> handles a portability/performance issue on behalf of the application.
> 
> -- 
> Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
>        http://www.geocities.com/SiliconValley/Park/9289/
>              Born in Roswell... married an alien...


Mime
View raw message