On Freitag, 21. August 2020 15:13:35 CEST Paolo Bonzini wrote: > On 20/08/20 14:00, Christian Schoenebeck wrote: > > One way would be a recursive type and logging a warning, which you > > obviously don't like; another option would be an assertion fault instead > > to make developers immediately aware about the double lock on early > > testing. Because on a large scale project like this, it is almost > > impossible for all developers to be aware about all implied locks. Don't > > you think so? > > > > At least IMO the worst case would be a double unlock on a non-recursive > > main thread mutex and running silently into undefined behaviour. > > Yes, more assertions are always fine. > > We were using errorcheck mutexes until a few years ago, unfortunately we > couldn't because they are broken with respect to fork (commit 24fa90499, > "qemu-thread: do not use PTHREAD_MUTEX_ERRORCHECK", 2015-03-05).
I had a go on this one; you still get EPERM when trying to pthread_mutex_unlock() from a forked child process on a PTHREAD_MUTEX_ERRORCHECK mutex locked by parent process. The common opinion though seems to be that unlocking parent's lock(s) by child process was illegal: https://groups.google.com/forum/#!topic/comp.programming.threads/ywMInaZjmqo https://sourceware.org/bugzilla/show_bug.cgi?id=2745 The relevant section from POSIX: fork - create a new process ... A process shall be created with a single thread. 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. https://pubs.opengroup.org/onlinepubs/9699919799/ Best regards, Christian Schoenebeck
