apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: [proposal] apr_thread_setconcurrency()
Date Mon, 17 Sep 2001 17:55:42 GMT

> If you create too many LWPs, you will lose a lot of optimizations
> that are present in Solaris (i.e. handover of a mutex to another
> thread in the same LWP - as discussed with bpane on dev@httpd
> recently).  If you don't create enough LWPs, you may enter a
> condition where the scheduler refuses to balance the processes
> correctly (it also acts as a ceiling).  0 lets the OS determine
> the concurrency (on Solaris).
> By setting a value, you are attempting to circumvent the OS
> scheduler.  If you ask it to set the concurrency on Solaris, it
> *will* create enough LWPs to equal that concurrency (as you
> create threads to be paired with LWPs).  This is not a hint, but a
> command.  (Yes, the man page for Solaris says that it is a hint,
> but it treats it as a command.)

I don't understand how you can say this.  According to single Unix:

"The pthread_setconcurrency() function allows an application to inform 
the threads implementation of its desired concurrency level, new_level. 
The actual level of concurrency provided by the implementation as a 
result of this function call is unspecified." 

If Solaris is using the setconcurrency value as a command, then it is
absolutely horked.

As for whether this is a valid thing to do because it circumvents the OS,
of course it's valid.  The OS is written to be generic, because that is the
only way to write a useful OS.  The programmer who is writing an
application knows better than the OS what the thread concurrency should
be for their application.  Generalized code performs worse than code than
is written for a specific application as a general rule.

The OS has to use a slow start to find the best concurrancy, because 
otherwise it will create too many LWP's.  With a web server, we know better
than the OS.

Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net

View raw message