Date: Tue, 09 Dec 2003 00:50:47 +0900 From: Alexander Nedotsukov <bland@FreeBSD.org> To: threads@FreeBSD.org Subject: Minor pthrerad_mutex_unlock() issue Message-ID: <3FD49DD7.60409@FreeBSD.org>
next in thread | raw e-mail | index | archive | help
Guys,
During recent bug hunting in ports I found wired (or better to say as I
think incorrect) behaviour of mutex unlocking code. Final unlock in code
snippet given bellow will fail with EINVAL. There is special '?' switch
in thr_mutex.c:mutex_lock_common() wich proceses mutexes with 0
initialized m_owner field this way. Normally it should rerturn EPERM I
guess. It was confusing to see EINVAL return from pthread_cond_wait() as
a side effect of this. I was looking for some memory corruption instead
of realizing that simply there is no prior mutex locking took place :-(
#include <stdio.h>
#include <pthread.h>
int main()
{
pthread_mutex_t m;
pthread_mutex_init(&m, NULL);
printf("%d", pthread_mutex_unlock(&m));
return 0;
}
I propose to remove special procesing for m_owner == NULL. Simple !=
curthread will be enough to report EPERM.
All the best,
Alexander.
ps.
Btw, pthread_cond_*() man pages need to be updated to indicate that
there is EPERM return code possible.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3FD49DD7.60409>