On Fri, Jul 2, 2021 at 3:19 PM Joe Orton <jor...@redhat.com> wrote: > > If pthread_mutex_timedlock() is not supported, apr_thread_mutex_unlock() > will take a locked mutex and immediately lock it again: > > https://github.com/apache/apr/blob/trunk/locks/unix/thread_mutex.c#L297 > > APR_DECLARE(apr_status_t) apr_thread_mutex_unlock(apr_thread_mutex_t *mutex) > { > apr_status_t status; > > if (mutex->cond) { > status = pthread_mutex_lock(&mutex->mutex); > > This is undefined behaviour unless APR ensures that mutex is recursive, > which it doesn't AFAICT.
When mutex->cond != NULL (ie !HAVE_PTHREAD_MUTEX_TIMEDLOCK), apr_thread_mutex_lock() and co don't leave mutex->mutex locked (the actual locking happens thanks to the ->cond wait on the ->locked flag). So apr_thread_mutex_unlock() can (and actually must) lock ->mutex to signal the ->cond and clear the ->locked. What am I missing? Regards; Yann.
