> 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
