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 ...
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
