Date: Tue, 30 Oct 2007 21:02:45 +0800 From: David Xu <bsddiy@126.com> To: Kris Kennaway <kris@FreeBSD.org> Cc: Daniel Eischen <deischen@FreeBSD.org>, cvs-src@FreeBSD.org, src-committers@FreeBSD.org, David Xu <davidxu@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: <47272B75.2020805@126.com> In-Reply-To: <47270410.2020802@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> <4726FB01.4060704@freebsd.org> <47270410.2020802@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote: > > PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP is just in <pthread.h>. > > /* > * Static initialization values. > */ > #define PTHREAD_MUTEX_INITIALIZER NULL > #define PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP NULL > #define PTHREAD_COND_INITIALIZER NULL > #define PTHREAD_RWLOCK_INITIALIZER NULL > >>>> 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. > > The code is already in mysql for use with glibc. It basically does > > #ifdef PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP > /* > * Use PTHREAD_MUTEX_ADAPTIVE_NP for the mutexes we know will benefit > * from it > */ > ... > #endif > > so it just works. > I can not find code in libthr set mutex's member field m_type to PTHREAD_MUTEX_ADAPTIVE_NP by your change, so how can it work as expected ? >> My code even needn't to recompile mysql and improve 40% performance. :-) > > OK, but that's not good enough. As I have mentioned, you should have > serious concerns about performance loss in other cases with an approach > that always spins in userland when acquiring any mutex. > >>> > 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. > > I don't understand what you are saying here. The glibc interface is > defined by glibc, so if we want to do something different then either > compatibility interfaces are needed (so what was the point of being > different other than "NIH"?), or we need to manually patch the > applications to do it "our way". > > Kris > See above, the code is not working ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47272B75.2020805>