Date: Tue, 30 Oct 2007 10:45:36 +0800 From: David Xu <davidxu@FreeBSD.org> To: Daniel Eischen <deischen@FreeBSD.org> Cc: cvs-src@FreeBSD.org, Kris Kennaway <kris@FreeBSD.org>, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libthr/thread thr_mutex.c src/lib/libkse/thread thr_mutex.c src/include pthread.h Message-ID: <47269AD0.3080906@freebsd.org> In-Reply-To: <Pine.GSO.4.64.0710292207140.19572@sea.ntplx.net> References: <200710292101.l9TL1mAE049561@repoman.freebsd.org> <47268F17.1000106@freebsd.org> <Pine.GSO.4.64.0710292207140.19572@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: > On Tue, 30 Oct 2007, David Xu wrote: > >> I am not sure PTHREAD_MUTEX_ADAPTIVE_NP is a correct solution, in fact >> I think this is Linux crap, shouldn't PTHREAD_PRIO_PROTECT and >> PTHREAD_PRIO_INHERIT mutex be adaptivly spinned ? >> also this commit does not change mutex_self_lock() to handle the >> PTHREAD_MUTEX_ADAPTIVE_NP, what is the PTHREAD_MUTEX_ADAPTIVE_NP >> definition when the mutex is already locked by the currect thread ? >> deadlock or return error code ? > > > I tend to agree with the "Linux crap" comment, but I hesitate > to use those words considering the recent sensor framework > incident ;-) > Isn't this commit an incident too ? :-) if it is not, then we should retire from FreeBSD now, as two thread library maintainers were bypassed. > As I said in previous email, I would rather see our default > mutex implementations improved instead of adding new interfaces. > If it's really necessary in the short term, perhaps an > environment variable that can be set to force all mutexes > to be adaptive (and when kern.smp.cpus > 1 perhaps?). > Yes, an environment variable is good idea. Regards, David Xu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47269AD0.3080906>