apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: apr_lock.h lock scope question
Date Thu, 21 Jun 2001 20:46:51 GMT
Aaron Bannert <aaron@ebuilt.com> writes:

> > > 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'm grateful... I hit the wrong key in my mail client when I responded
to you the first time.

> 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?)?

APR just uses some platform syscall.  It is really the behavior of the
platform syscall we're talking about.  APR hasn't done anything for
APR_CROSS_PROCESS to give different semantics than the platform syscal
w.r.t. blocking out other threads in the same process.

example platform/mechanism where other theads in the same process
aren't blocked out:

. linux with SysV sem locking

counter example:

. OS/390 with SysV sem locking

> 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. 

I suppose "scope of accessability" means which address spaces can
access the lock?  And you don't like that APR decides where to
allocate its representation of the lock?  Why?

>                                               Typically that owner would
> place the apr_lock_t in the same physicaly location as the data it's
> locking. 

What is it that you want to do that you can't?  I'm not sure what
you're getting at :)

>            In addition, it seems we're mixing provisional and mandatory
> locks under the same API.

Are you using the term "provisional lock" for the reader/writer locks
in APR?  There is no support for provisional locks (where the system
grants you exclusive access to a resource but may revoke it later and
force you to undo any changes) in APR.

> 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? 

maybe if I know what you refer to as "provisional lock" I can make a
comment... 

>                   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?

I think you need to be very explicit about what you see that you don't
like.  I don't really know what your talking about.

It would seem that for the lock operations supported by APR there is a
platform-independent interface for the application to use.  I
sometimes think it is missing some cool stuff but that is another
issue.

-- 
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