Bug #2763
closedpthread_mutex_destroy fails with error EINVAL(22) when run from main thread
0%
Description
The following program when compiled with -pthread on DragonFly fails with assertion 22, while it works on Linux:
#include <assert.h>
#include <pthread.h>
int main() {
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
assert(pthread_mutex_destroy(&lock) == 0); // returns EINVAL (22)
}
While when it goes through a lock/unlock cycle or pthread_mutex_init() is called before,
the pthread_mutex_destroy() does not fail with EINVAL:
int main() {
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_init(&lock, NULL);
assert(pthread_mutex_destroy(&lock) == 0); // OK
}
I propose the attached patch to return success if pthread_mutex_destroy() is called
for the PTHREAD_MUTEX_INITIALIZER case.
Files
Updated by swildner almost 10 years ago
Correct me if I'm wrong, but it looks as with this patch, pthread_mutex_destroy()ing a mutex twice would no longer result in EINVAL. Do we want that?
Updated by mneumann almost 10 years ago
Am 08.01.2015 um 13:05 schrieb bugtracker-admin@leaf.dragonflybsd.org:
> Issue #2763 has been updated by swildner.
>
>
> Correct me if I'm wrong, but it looks as with this patch,
pthread_mutex_destroy()ing a mutex twice would no longer result in
EINVAL. Do we want that?
Agreed! It's better to leave as is unless we want to use a sentinel
value of say (void*)1 to detect an already destroyed mutex. Btw, same
problem occurs for condvar and rwlock.
Regards,
Michael
Updated by mneumann almost 10 years ago
- Status changed from New to Resolved