cvs commit: src/lib/libthr/thread thr_mutex.c src/lib/libkse/thread thr_mutex.c src/include pthread.h

[David Xu]

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.