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 Thu, 21 Jun 2001 18:57:51 GMT
On Thu, Jun 21, 2001 at 02:20:11PM -0400, Jeff Trawick wrote:
> Aaron Bannert <aaron@ebuilt.com> writes:
> 
> > I apologise if this was already discussed, but I'm curious why there
> > are three scope types instead of just two?
> > 
> > (from include/apr_lock.h:103)
> > 
> >  * @param scope The scope of the lock to create, one of:
> >  * <PRE>
> >  *            APR_CROSS_PROCESS    lock processes from the protected area.
> >  *            APR_INTRAPROCESS     lock threads from the protected area.
> >  *            APR_LOCKALL          lock processes and threads from the
> >  *                                 protected area.
> >  * </PRE>
> > 
> > Also the note further down:
> > 
> >  * @tip APR_CROSS_PROCESS may lock both processes and threads, but it is
> >  *      only guaranteed to lock processes.
> > 
> > 
> > I'm just curious if there actually are scenarios where an apr_lock_t
> > is usable across processes but not in the same process?
> 
> yes...  On various systems the syscalls we use for an
> APR_CROSS_PROCESS lock will not block out other threads in same
> process as the thread holding the lock though they will block out
> threads in other processes.
> 
> I guess that is what you mean by "is usable."  If you mean "when
> would it be okay to use a lock that doesn't lock out other threads in
> the same process" then that depends on your application.

[I hope you don't mind that I have replied back to the list]

I was asking about the apr implementation, nothing specific to an
application.  Does anyone know which platforms present this kind of
behavior (and what are the underlying mechanisms -- flock, pthread et
al, etc?)?

I'm looking through this locking code and it seems a bit tangential to
other lock implementations I've seen. Normally the lock knows nothing
about it's scope of accessability (intra-process vs. inter/cross-process),
since that is taken care of the lock owner. Typically that owner would
place the apr_lock_t in the same physicaly location as the data it's
locking. In addition, it seems we're mixing provisional and mandatory
locks under the same API.

Before I propose any alternative solutions, I'd like to understand what
the current implementation of locks are being used for. Is there a need
to provide a single lock API for transparently handling provisional and
mandatory locks? Furthermore, would it be difficult for an application
using locks to specify its locking requirement in a platform-independent
way that still meets the scope requirements of the data it's trying
to protect?

-aaron


Mime
View raw message