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 Mon, 17 Sep 2001 03:54:08 GMT
On Sun, Sep 16, 2001 at 08:30:15PM -0700, Aaron Bannert wrote:
> Agreed, but instead of adding sleep we should:
> a) call pthread_setconcurrency()
> b) devise a more life-like test
> c) not do anything cause it's working fine
> 
> testlockperf is really just trying to gauge the overhead from the
> mutex routines, and I think it does a very good job of that. The secondary
> purpose of testlockperf is to compare the old locking API to the new
> one.

Without enforcing the lock routines to be run in parallel, you aren't
testing the expected common case - therefore, it isn't a good test.
Yes, you could call pthread_setconcurrency(), but I think you are 
going to misjudge the appropriate number to pass to it (as I think 
there is no number that makes sense for all cases).  If you really 
want pthread_setconcurrency to equal the number of threads, you want 
to enforce a bound thread implementation (which is different than 
creating a thread as bound with a multiplexed thread implementation).

At this point, we should both shut up and get some numbers.  -- justin


Mime
View raw message