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 23:12:58 GMT
On Sun, Sep 16, 2001 at 03:29:37PM -0700, Aaron Bannert wrote:
> (just a question, when you say "bound thread impl" you mean
> /usr/lib/lwp/libpthread, right? and the "LWP version" is the default
> /usr/lib/libpthread. Let me know if I have this backward. Maybe
> "LWP version" isn't the best name for the two libs, since they both
> do LWPs.)

Yup.   More precisely /usr/lib/lwp/libthread.so is the "alternate"
version and /usr/lib/libthread.so is the "default" version.  They
are binary compatible (as far as we care) - therefore the
LD_LIBRARY_PATH trick works.  With Solaris 8 (first one to have
this alternate version), the default is to use LWPs and the 
alternate is bound threads.  AFAIK, Solaris 9 switches them.

> I don't really see this as a scheduling quirk on Solaris. I think we
> would all agree that the same "work" is performed in each of the 4 tests,
> with or without sleeps, and with or without setconcurrency.  It is also
> obvious that since the same "work" is performed in each case, that the
> obvious winner for this made-up performance test is the one that does
> the work the fastest; which happens to be the one that creates no new
> LWPs and therefore minimizes the number of kernel context switches.

What happens is that when the sleeps are not present, three of the
threads do not have a chance to execute the test function (they are
stuck in the libc thread_start function).  They are monopolized by 
the one thread that raced to the beginning and started working.  The 
sleep allows all of the threads to hit the lock acquire within
testlockperf (remember that the code that spawns the threads has the
lock so the threads can't acquire it - they go to sleep).  Once the 
spawning thread releases the lock, all of the threads now wakeup
and compete.  Watch it with gdb and pstack on a MP box.  =-)

> But of course that case is not terribly relevant for something like
> httpd-2.0 on a big SMP box, where the optimal case (of which there are
> many dimentions) can not be known to the underlying thread/LWP creation
> agent. That is the key issue at hand here. We, as _users_ of this API
> would like to maximize each of {requests/second, time/request, number of
> simultaneous connections} where the LWP creation agent is just trying to
> get the work done with the least amount of context switching. The dials it
> has to play with are numerous, and so it must perform a delicate linear
> programming task in an attempt to meet the same goals as the application
> programmer. I don't claim that setconcurrency is the way to reduce the
> number of variables in this equation, but I do suggest we may want to
> take this into consideration when trying to make our threaded algorithms
> work the way we expect them to.

I just don't think it is going to get us what you want.  I think
the net result with setconcurrency on Solaris with LWPs is to 
circumvent its balancing algorithms so that it creates too many 
LWPs.  I think this is the wrong way to attack this problem and 
goes against the design of their thread library.  On all other 
platforms (and with bound thread impl on Solaris), setconcurrency 
is an ignored hint.  -- justin

View raw message