Having taken the time to review some of the proc mutex code, it seems both the process-shared pthread mutexes and POSIX semaphores differ from the other locking types on Unix in two significant ways:
1) for both types, if a process segfaults whilst holding the lock, the mutex is left in an undefined (i.e. probably locked) state [1]. For the other lock types, the mutex is unlocked and safe to use. 2) destroying a mutex in one process leaves it in an undefined state in the other processes which forked and inherited the apr_proc_mutex_t. For the other lock types behaviour varies but is well-defined. This trade-off against better performance for these two types doesn't seem acceptable: e.g. for httpd/worker, a module segfault in a single thread can cause a complete denial of service if the listener thread in that process has the accept mutex locked. So, I'm proposing that _POSIXSEM or _PROC_PTHREAD should never be made the default locking mechanism. Nothing to stop those who understand the trade-off making an informed choice, of course. joe [1] supposedly on Solaris, this is solved for pthread mutexes by setting the "robust" attribute, but evidence in bugzilla from at least one tester was that mod_include segfaults using worker on Solaris could hang the server.
