Date: Tue, 30 Oct 2007 17:36:01 +0800 From: David Xu <davidxu@FreeBSD.org> To: Kris Kennaway <kris@FreeBSD.org> Cc: Daniel Eischen <deischen@FreeBSD.org>, cvs-src@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: <4726FB01.4060704@freebsd.org> In-Reply-To: <4726F7E9.2060403@FreeBSD.org> References: <200710292101.l9TL1mAE049561@repoman.freebsd.org> <47268F17.1000106@freebsd.org> <Pine.GSO.4.64.0710292207140.19572@sea.ntplx.net> <4726E9AB.4050209@FreeBSD.org> <4726F130.2060709@freebsd.org> <4726F7E9.2060403@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote: >> >> I object adding PTHREAD_MUTEX_ADAPTIVE_NP, because there is no >> corresponding PTHREAD_ADPATIVE_MUTEX_INITIALIZER, but normal >> pthread mutex has macro PTHREAD_MUTEX_INITIALIZER, so it is >> inconsistent, maybe adding pthread_mutexattr_setspin() etcs are better >> than this hack for our implementation, it is not portable though. > > > There is an PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP, which is again the > name that existing applications expect for it. The fact that this > interface *already exists* in other operating systems and *is already > used* by real applications overrides objections about one name choice vs > another. The best you can argue for is to use a different name with a > compatibility #define, but I dont see the point of this. > I didn't find any place in thr_mutex.c that you have set PTHREAD_MUTEX_ADAPTIVE_NP type, or I missed something ? >> I remembered mysql uses this macro to initialize spin mutex, and you >> indead needs a patch to let it work > > > No, with the code I committed mysql detects and uses it out of the box, > without requiring any patches. It is easy to measure the resulting 30% > performance improvement at high loads ;-) > see above, I didn't see any code set PTHREAD_MUTEX_ADAPTIVE_NP type. My code even needn't to recompile mysql and improve 40% performance. :-) > > in fact spin mutex in libthr is > >> arguable, normally you can use pthread_mutex_trylock() in application >> to simulate spinning, adding such mutex type it in libthr just simplified >> it, but it is not portable. > > > That is what the "_NP" indicates (although remember that this interface > is compatible with glibc). > > Kris > I am waiting for others, since this is first time we have to add a new mutex type.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4726FB01.4060704>