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 Fri, 22 Jun 2001 03:22:57 GMT
On Thu, Jun 21, 2001 at 04:46:51PM -0400, Jeff Trawick wrote:
> Aaron Bannert <aaron@ebuilt.com> writes:
[snip]
> > 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 :)

I guess what I'm looking for is a lightweight thread syncronization
API. This maybe stretching the mantra of APR ("implement what you need
when you need it"), but I'm interested in putting some more design effort
into the locking facilities that APR provides. Would it be of any use
at this time to rethink some of the locking APIs? (ie does
apr_lock_child_init really belong in apr/locks/*/locks.c?)

The way I see it right now, APR provides one interface to two distinct
locking features: thread syncronization (aka APR_INTRAPROCESS), and
process syncronization (APR_CROSS_PROCESS). In my mind these are totally
different things that seem to have specific uses in the code. Correct
me if I'm wrong, but I only see APR_CROSS_PROCESS being used in a few
places, like the call to accept(), and APR_INTRAPROCESS is used everywhere
else for generic mutex functionality. For the latter, why don't we just
use/extend POSIX?

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

Oops! My mistake..when I said "provisional" I actually meant "advisory".
I don't know where I got that first one from...


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

I apoligise for being so vague in the previous message. Let me see if
I can provide a quick requirements proposal here:

- global resource syncronization (Will modules perhaps need true cross-
  process syncronization, or will the the process-group-only locking that
  we have now suffice? I suspect module authors will want true cross-process
  sync as they look for more creative ways to connect their [legacy] apps
  to apache).
   -- the weight of these calls will depend partially on platform support.

- mutexes -- ideally this is just POSIX. Regardless, this is very lightweight.
  (much more lightweight and well defined than the current one-size-fits-all
   apr_lock_*() stuff :)

- conditionals and rwlocks (these pretty much go together, and would be
  built upon the mutex routines) -- much more heavy than simple mutexes,
  but IMHO widely useful throughout httpd and the modules.


If this sounds like something we could use, than I can cook up function
names for the interface outlined above, and we can have something more
concrete to stare at.

-aaron


Mime
View raw message