Ian Holsman wrote:
Aaron Bannert wrote:
I'd like to propose we add a call that gives a hint to the OS as to the level of concurrency we wish to have. This would mirror pthread_setconcurrency(), and would be a simple call to that on operating systems that have it available. On other platforms it would be simple noop.
Give me some +1s and I'll submit a patch.
-aaron
+1 IF the number you set it to is a hint, and solaris can changes the concurrency afterwards according to the load on the system/internal guidelines.
Oh... I ran the the testlockperf code on the 8-way box, with the pthread_setconcurrency calls commented out, and with the concurrency calls put in (setting them to 8). results are as follows
(without setconcurrency) APR Lock Performance Test ==============
apr_lock(INTRAPROCESS, MUTEX) Lock Tests Initializing the apr_lock_t OK Starting all the threads OK microseconds: 9373710 usec apr_thread_mutex_t Tests Initializing the apr_thread_mutex_t OK Starting all the threads OK microseconds: 7304314 usec apr_lock(INTRAPROCESS, READWRITE) Lock Tests Initializing the apr_lock_t OK microseconds: 11247506 usec apr_thread_mutex_t Tests Initializing the apr_thread_mutex_t OK
microseconds: 8148914 usec
(with pthread_setconcurrency(8) where you put the comments) APR Lock Performance Test ==============
apr_lock(INTRAPROCESS, MUTEX) Lock Tests Initializing the apr_lock_t OK Starting all the threads OK microseconds: 20054346 usec apr_thread_mutex_t Tests Initializing the apr_thread_mutex_t OK Starting all the threads OK microseconds: 16979410 usec apr_lock(INTRAPROCESS, READWRITE) Lock Tests Initializing the apr_lock_t OK
microseconds: 247538114 usec apr_thread_mutex_t Tests Initializing the apr_thread_mutex_t OK microseconds: 250328270 usec
(I didn't wait long enough)
--It just sits at this point.... (CVS Code is a couple of day old if that makes a difference)
