pthread_mutex_unlock function unexpectedly fails when called in child process
on a mutex, which:
* has PTHREAD_MUTEX_ERRORCHECK or PTHREAD_MUTEX_RECURSIVE attribute
* has been locked in parent process
Possibility of unlocking of a mutex locked in parent process is typically used
in handlers installed by pthread_atfork routine and is supposed to work.
int main(int argc, char *argv)
pid = fork();
err = pthread_mutex_unlock(&mutex);
printf("pid=%d, err=%d\n", pid, err);
err should be 0 both on child and on parent.
After fork only async-safe functions can be called. Therefore the code is
completely bogus. Don't file bugs if you have no clue what you're talking about.
*** Bug 2746 has been marked as a duplicate of this bug. ***
I have a clue: see "RATIONALE" section of "pthread_atfork" specification in:
We can read there:
"The expected usage is that the prepare handler acquires all mutex locks and
the other two fork handlers release them."
But this does not work with glibc, because unlocking mutex from "child" handler
What from "Consequently, to avoid errors, the child process may only execute
async-signal-safe operations until such time as one of the exec functions is
called." you don't understand?
In the child you of course are never supposed to unlock the lock, but instead
Also, the child doesn't own the mutex, it is owned by the thread that called
fork (), so for error checking mutex returning EPERM is certainly valid behavior.
"If a multi-threaded process calls fork(), the new process shall contain a
replica of the calling thread and its entire address space, possibly including
the states of mutexes and other resources. Consequently, to avoid errors, the
child process may only execute async-signal-safe operations until such time as
one of the exec functions is called"
This is about multi-threaded processes only. Process in my example program is
single-threaded. So async-safety does not apply.
Also, do you understand "replica of the calling thread and its entire address
space, possibly including the states of mutexes and other resources" ? If the
thread owns mutex in parent process, it should own the mutex in child, too.
I think this may not apply to mutexes with PTHREAD_PROCESS_SHARED attribute,
although the standard does not say about this.
Dammit, leave this closed. You are wrong on all counts, from not async-safe
applying to using pthread_mutex_unlock in the first place. If you reopen this
again or file another stupid bug like this I have no choice but to make sure you
cannot do it again in future.
OK, sorry. I have suggested with pthreads implementation under AIX.