apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: [proposal] apr_thread_setconcurrency()
Date Sun, 16 Sep 2001 21:02:39 GMT
On Sun, Sep 16, 2001 at 01:53:42PM -0700, Ian Holsman wrote:
> $ ./testlockperf
> APR Lock Performance Test
> ==============
> 
> apr_lock(INTRAPROCESS, MUTEX) Lock Tests
>     Initializing the apr_lock_t                             OK
>     Starting all the threads                                OK
> microseconds: 9634489 usec
> apr_thread_mutex_t Tests
>     Initializing the apr_thread_mutex_t                     OK
>     Starting all the threads                                OK
> microseconds: 7333845 usec
> apr_lock(INTRAPROCESS, READWRITE) Lock Tests
>     Initializing the apr_lock_t                             OK
> microseconds: 11365100 usec
> apr_thread_mutex_t Tests
>     Initializing the apr_thread_mutex_t                     OK
> microseconds: 8443761 usec
> 
> $ export LD_LIBRARY_PATH=/usr/lib/lwp/
> 
> $ ./testlockperf
> APR Lock Performance Test
> ==============
> 
> apr_lock(INTRAPROCESS, MUTEX) Lock Tests
>     Initializing the apr_lock_t                             OK
>     Starting all the threads                                OK
> microseconds: 25322674 usec
> apr_thread_mutex_t Tests
>     Initializing the apr_thread_mutex_t                     OK
>     Starting all the threads                                OK
> microseconds: 23590762 usec
> apr_lock(INTRAPROCESS, READWRITE) Lock Tests
>     Initializing the apr_lock_t                             OK
> microseconds: 23106303 usec
> apr_thread_mutex_t Tests
>     Initializing the apr_thread_mutex_t                     OK
> microseconds: 19515490 usec

This is on a 8-way box, right?  Those numbers look about right
for the bound thread implementation.  However, the LWP version
still looks like it isn't doing the right thing.

I think you probably need this patch for the LWP version. 
I'm not sure whether setconcurrency will produce the same 
effect - it might.

I'm not going to commit this because I know it's the wrong thing 
(should be condition vars I think), but it solves the scheduling 
quirk on Solaris for now.  -- justin

Index: testlockperf.c
===================================================================
RCS file: /home/cvs/apr/test/testlockperf.c,v
retrieving revision 1.4
diff -u -r1.4 testlockperf.c
--- testlockperf.c	2001/09/16 17:15:39	1.4
+++ testlockperf.c	2001/09/16 20:47:37
@@ -176,6 +176,7 @@
     }
     printf("OK\n");
 
+    apr_sleep(10000);
     time_start = apr_time_now();
     apr_lock_release(inter_lock);
 
@@ -226,6 +227,7 @@
     }
     printf("OK\n");
 
+    apr_sleep(10000);
     time_start = apr_time_now();
     apr_thread_mutex_unlock(thread_lock);
 
@@ -275,6 +277,7 @@
         return s1;
     }
 
+    apr_sleep(10000);
     time_start = apr_time_now();
     apr_lock_release(inter_rwlock);
 
@@ -323,6 +326,7 @@
         return s1;
     }
 
+    apr_sleep(10000);
     time_start = apr_time_now();
     apr_thread_rwlock_unlock(thread_rwlock);
 


Mime
View raw message