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:13:25 GMT
On Sun, Sep 16, 2001 at 07:59:19PM -0700, Aaron Bannert wrote:
> I don't think it's a quirk of the thread library, I think it's
> fully expected. For the sake of others, here's an excerpt from the
> Solaris 8 pthread_setconcurrency(3THR) man page:

In testlockperf, you are assuming that all of the threads have 
started and will compete for the locks.  In a M:N implementation, 
this assumption is false.  You end up executing in serial rather
than in parallel.  This only occurs because you never hit a
user-scheduler entry point in testlockperf.  In the case of a MPM,
you will be hitting them left and right.  =-)

Therefore, you need to devise a strategy within testlockperf to 
ensure that all of the threads are ready to compete before 
continuing the test.  The suggested sleep is one way - condition
variables *may* be possible, but it isn't completely obvious to
me how that would work.  -- justin

P.S. If you are running a site where you get 50,000 hits a minute,
you shouldn't have MRPC at 10,000.  I'd be curious to see what
cnet runs with.


Mime
View raw message