Skip site navigation (1)Skip section navigation (2)
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>