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...@ebuilt.com> on 2001/06/21 19:01:41 UTC
apr_lock.h lock scope question
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?
-aaron
Re: apr_lock.h lock scope question
Posted by kevin seguin <se...@motive.com>.
>
> > - 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.
>
> Conditionals weren't portable when I looked at them. Basically, Windows
> couldn't do them, but I'm not a windows programmer, and I didn't look at
> it too hard.
>
so, i'm not exactly sure what you guys are talking about when you say
"conditionals", but anyway... i've recently started looking into using
apr for some stuff, and one of the things i'd like to have but i don't
see there is conditions (like pthread_cond_t) that can be used for
communicating events between threads. essentially, this:
<psuedo code>
struct apr_condition_t;
APR_DECLARE(apr_status_t) apr_new_condition(apr_condition_t* cond);
APR_DECLARE(apr_status_t) apr_destroy_condition(apr_condition_t* cond);
APR_DECLARE(apr_status_t) apr_condition_wait(apr_condition_t* cond, int
sec, int nsec);
APR_DECLARE(apr_status_t) apr_condition_signal(apr_condition_t* cond);
</psuedo code>
is this similar to what you mean by conditionals? i have some c code
that implements this that i have used on both windows and unix
(solaris). the unix side just uses pthreads stuff.
is this kind of functionality already in apr and i'm missing it? if
not, is it something that others would find useful? i'd have no problem
donating my existing code ;-)
-kevin.
Re: apr_lock.h lock scope question
Posted by rb...@covalent.net.
> 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?
If you use APR_INTRAPROCESS, you will get a light-weight thread locking
mechanism. What more are you looking for. In reality, for thread
locking, we always end up using pthreads mutex's on Unix.
> - 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.
This is provided using APR_CROSSPROCESS
> - 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 :)
This is what we do.
> - 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.
Conditionals weren't portable when I looked at them. Basically, Windows
couldn't do them, but I'm not a windows programmer, and I didn't look at
it too hard.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: apr_lock.h lock scope question
Posted by Aaron Bannert <aa...@ebuilt.com>.
On Thu, Jun 21, 2001 at 04:46:51PM -0400, Jeff Trawick wrote:
> Aaron Bannert <aa...@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
Re: apr_lock.h lock scope question
Posted by Jeff Trawick <tr...@attglobal.net>.
Aaron Bannert <aa...@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...
Re: apr_lock.h lock scope question
Posted by Aaron Bannert <aa...@ebuilt.com>.
On Thu, Jun 21, 2001 at 02:20:11PM -0400, Jeff Trawick wrote:
> Aaron Bannert <aa...@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