cvs commit: src/lib/libthr/thread thr_mutex.c
src/lib/libkse/thread thr_mutex.c src/include pthread.h
davidxu at FreeBSD.org
Tue Oct 30 02:35:11 PDT 2007
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).
I am waiting for others, since this is first time we have to add a new
More information about the cvs-src