Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 25 Jun 2001 10:06:31 -0700
From: Aaron Bannert <aaron@ebuilt.com>
To: Jeff Trawick <trawick@attglobal.net>
Cc: dev@apr.apache.org
Subject: Re: apr_lock.h lock scope question
Message-ID: <20010625100631.F10809@ebuilt.com>
References: <20010622073711.K5701@ebuilt.com>
 <m3wv64zifr.fsf@adsl-77-241-65.rdu.bellsouth.net>
 <20010622082701.L5701@ebuilt.com>
 <m3y9qg1sod.fsf@adsl-77-241-65.rdu.bellsouth.net>
 <20010625093544.C10809@ebuilt.com>
 <m3vglk5xdn.fsf@adsl-77-241-65.rdu.bellsouth.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <m3vglk5xdn.fsf@adsl-77-241-65.rdu.bellsouth.net>;
 from trawick@attglobal.net on Mon, Jun 25, 2001 at 12:37:24PM -0400

> What this means is that to block out *all* other processes and
> threads, unless we're on a system where APR_PROCESS_LOCK_IS_GLOBAL is
> defined, we need to get an interprocess lock (to block out everything
> but threads in our own process) as well as a intraprocess lock (to
> block out other threads in our own process).

Fine, so interprocess locks conditionally depend on intraprocess locks,
but not vice versa. So let's take all this extra overhead out of
calls that could be for simple intraprocess mutexes.

> If we use a kernel mechanism for interprocess locking which doesn't
> block out other threads in the same process then this certainly can
> happen.
> 
> Generally, APR does use such a kernel mechanism on Unix.

Right, but this happens at a much lower level than "acquire a cross-process
lock on any platform".


I think it would be best to provide a two-layered lock subsystem:

- The high layer would provide real simple, general, and cross-platform
  calls for functionality like "give me my fastest mutex impl", or
  "acquire a cross-process lock on any platform".
  - This high layer would depend on the lower layer.

- The lower layer would introduce the implementation-by-function-pointer
  concept you proposed this morning. It would provide more-platform-specific
  calls that would allow runtime flexibility/optimization when choosing
  an implementation for some locking feature.


It is fine if these layers are really just hidden function pointers, but
I would prefer if they were well-defined at the higher-layer.

-aaron