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 Mon, 25 Jun 2001 17:06:31 GMT
> 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.


View raw message